控制器模型

从前面的学习中，我们可以对 Pod 做一个总结：Pod 这个看起来复杂的对象，实际上就是对容器的进一步抽象和封装。Pod，就是容器的升级版，它对容器进行了组合，添加了更多的属性和字段。
下面是一个 Deployment 这个控制器的一个例子：

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

该 Deployment 的编排动作是确保携带了 app=nginx 标签的 Pod 的个数，永远等于 spec.replicas 指定的个数。
Kubernetes 中的控制器都遵循一个通用的编排模式，即：控制循环(control lool)。比如，现在有一种待编排的对象 X，它有一个对应的控制器。可以使用伪代码描述这个控制循环。

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

在具体实现中，实际状态往往来自于 Kubernetes 集群本身；而期望状态，一般来自于用户提交的 YAML 文件。
我们可以对 Deployment 和其他的控制器做一个总结：

如上图所示，类似 Deployment 这样的一个控制器，实际上是由上半部分的控制器定义和下半部分的被控制对象的模板组成的。