k8s的容器编排

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上产生，从而系统自动恢复。

 

 

1、准备好一个包含应用程序的Deployment的yml文件，然后通过kubectl客户端工具发送给ApiServer。
2、ApiServer接收到客户端的请求并将资源内容存储到数据库(etcd)中。
3、Controller组件(包括scheduler、replication、endpoint)监控资源变化并作出反应。
4、ReplicaSet检查数据库变化，创建期望数量的pod实例。
5、Scheduler再次检查数据库变化，发现尚未被分配到具体执行节点(node)的Pod，然后根据一组相关规则将pod分配到可以运行它们的节点上，并更新数据库，记录pod分配情况。
6、Kubelete监控数据库变化，管理后续pod的生命周期，发现被分配到它所在的节点上运行的那些pod。如果找到新pod，则会在该节点上运行这个新pod。
7、kuberproxy运行在集群各个主机上，管理网络通信，如服务发现、负载均衡。例如当有数据发送到主机时，将其路由到正确的pod或容器。对于从主机上发出的数据，它可以基于请求地址发现远程服务器，并将数据正确路由，在某些情况下会使用轮训调度算法(Round-robin)将请求发送到集群中的多个实例。