标签：node 容器 主机 编排 etcd Pod k8s pod

1、K8S是如何对容器编排？

在K8S集群中，容器并非最小的单位，K8S集群中最小的调度单位是Pod，容器则被封装在Pod之中。由此可知，一个容器或多个容器可以同属于在一个Pod之中。 2、Pod是怎么创建出来的？ Pod并不是无缘无故跑出来的，它是一个抽象的逻辑概念，那么Pod是如何创建的呢？Pod是由Pod控制器进行管理控制，其代表性的Pod控制器有Deployment、StatefulSet等。 3、Pod资源组成的应用如何提供外部访问的？ Pod组成的应用是通过Service这类抽象资源提供内部和外部访问的，但是service的外部访问需要端口的映射，带来的是端口映射的麻烦和操作的繁琐。为此还有一种提供外部访问的资源叫做Ingress。 4、Service又是怎么关联到Pod呢？ 在上面说的Pod是由Pod控制器进行管理控制，对Pod资源对象的期望状态进行自动管理。而在Pod控制器是通过一个YAML的文件进行定义Pod资源对象的。在该文件中，还会对Pod资源对象进行打标签，用于Pod的辨识，而Servcie就是通过标签选择器，关联至同一标签类型的Pod资源对象。这样就实现了从service-->pod-->container的一个过程。 5、Pod的怎么创建逻辑流程是怎样的？ （1）客户端提交创建请求，可以通过API Server的Restful API，也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML。 （2）API Server处理用户请求，存储Pod数据到etcd。 （3）调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。 （4）过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。 （5）主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。 （6）选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中。 （7）kubelet根据调度结果执行Pod创建操作： 绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器。   三、各类接口是如何调用 当我们通过kubectrl create命令创建一个RC资源对象时，kubectrl通过create rc这个rest接口将数据提交到api server， 随后api server将数据写入etcd里持久保存，与此同时，controller manager 在watch 所有的rc资源对象，因此一旦有rc对象被写入到etcd中，controller manager就得到了通知， 它会读取rc的定义，然后比较rc中所控制的pod的实际副本数与期待值的差异，然后采取对应的行动。   此刻，controller manager发现集群中还没有对应的pod实例，就根据rc里的pod模板(template)定义， 创建一个pod并通过apiserver保存到etcd中。   类似地，scheduler进程在watch所有pod，一旦它发现系统产生了一个新生的pod， 就开始执行调度逻辑，为它安排一个新家(node)，如果一切顺利，此pod就被安排到某个node节点上，即binding to a node。   接下来，scheduler进程就把这个信息及pod状态更新到etcd里，最后目标node节点上的kubelet监听到有新的pod被安排到自己这里来了， 于是就是安排pod里的定义，拉取容器的镜像并且创建对应的容器，当容器成功创建后，kubelet进程再把pod的状态更新为running并通过api server更新到etcd中。   如果此pod还有对应的service，那么接下来就轮到kube-proxy出场了，每个node上的kube-proxy进程会监听所有service及这些service对应的pod实例的变化，一旦发现有变化,就会在所在node节点上的iptables里增加或者删除对应的nat转发规则，最终实现了service的智能负载均衡功能，这一切都是自动完成的，无须人工干预。   如果某个node宕机，则会发生什么事情呢？假如某个node宕机一段时间，则因为此节点上再没有kubelet进程定时汇报这些pod的状态,因此这个node上的所有pod实例会被判定为失败状态，此时controller manager会将这些pod删除并产生新的pod实例，于是这些pod就会被调度到其它node上产生，从而系统自动恢复。    

标签：node,容器,主机,编排,etcd,Pod,k8s,pod
来源： https://www.cnblogs.com/muzinan110/p/11105794.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。