云计算之k8s系列_第十一回

上一回，我们了解了pod的用法，知道了pod这个API对象的各个字段。接下来，看看编排这
个k8s中最核心的功能。

pod这个看似复杂的API对象，实际上就是对容器的进一步抽象和封装而已。换句话说，容器
镜像虽然好用，但是容器对于描述应用来说，还是太过简单了。所以，pod对象，其实就是
容器的升级版。它对容器进行了组合，添加了更多的属性和字段，使得k8s可以更轻松的操
作它。

现在，我们一起来回顾一下nginx-deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

这个Deployment定义的编排动作非常简单，确保携带了app=nginx标签的pod的个数，永远等
于spec.replicas指定的个数。 也就是说，如果携带app=nginx标签的pod大于2个，旧的pod
就会被删除；反之，就会有新的pod被创建。在k8s架构中，由kube-controller-manager组
件对各类控制器进行控制。

k8s项目的controller目录：

 

$ ls              
deployment/             job/                    podautoscaler/          
cloud/                  disruption/             namespace/              
replicaset/             serviceaccount/         volume/
cronjob/                garbagecollector/       nodelifecycle/          
replication/            statefulset/            daemon/

 

这个目录下面的每一个控制器，都以独有的方式负责某种编排功能。它们都遵循k8s项目中
的一个通用编排模式，即：控制循环（control loop）。这里可以使用go伪代码，看一看这
个控制循环：

for {
  实际状态 := 获取集群中对象 X 的实际状态（Actual State）
  期望状态 := 获取集群中对象 X 的期望状态（Desired State）
  if 实际状态 == 期望状态{
    什么都不做
  } else {
    执行编排动作，将实际状态调整为期望状态
  }
}

实际状态来自于k8s集群本身：比如，kubelet通过心跳汇报的容器状态和节点状态，或者监
控系统中保存的应用监控数据，或者控制器主动收集的它自己感兴趣的信息，这些都是常见
的实际状态的来源。

期望状态，来自于用户提交的YAML文件：比如，Deployment对象中Replicas字段的值，很明
显，这些信息往往都保存在Etcd中。

deployment对控制器模型的实现：

​1.Deployment控制器从头Etcd中获取到所有携带了app:nginx标签的pod，然后统计它们的数量，这就是实际状态；
2.Deployment对象的Replicas字段的值就是期望状态；
3.Deployment控制器将两个状态作比较，来确定删还是创建pod。

可以看出，一个k8s对象的主要编排逻辑，实际上是在第三步的对比阶段完成的。

像Deployment这种控制器的设计原理，就是用一种对象管理另一种对象的艺术。其中，控制
器对象本身，负责定义被管理对象的期望状态。比如，Deployment里的replicas=2这个字段
。而被控制对象的定义，则来自一个“模板”。比如Deployment里的template字段。

Deployment这个template字段里的内容，就是一个标准pod对象API的定义。而所有被这个
Deployment管理的pod实例，其实都是根据这个template字段的内容创建出来的。这个
template字段，被称作PodTemplate（Pod模板）。

像Deployment这样的一个控制器，实际上都是由上半部分的控制器定义（包括期望状态）和
下半部分的被控制对象的模板组成的。

这就是为什么，在所有API对象的Metadata里，都有一个字段叫做ownerReference，用于保
存当前这个API对象的拥有者（Owner）的信息。

上面那个YAML文件，它创建出来的pod的ownerReference就是nginx-deployment。

总结：

跟Deployment相似，这些控制循环最后的执行结果，那么创建、更新pod（或其他API对象、
资源），要么就是删除一些已经存在的pod（或者其他的API对象、资源）。这个实现思路，
正是k8s项目进行容器编排的核心原理。