（1）Deployment 作用是确保 Pod 副本数量，能够保证 Pod 数量与期望值一样，会有自恢复功能。简洁地说：具有 水平扩展 / 收缩 功能。
可能好奇的是在 kubernetes 中是谁在执行这些控制器的，它就是 kube-controller-manager 组件。实际上，这个组件，就是一系列控制器的集合。
for {
实际状态 := 获取集群中对象 X 的实际状态
期望状态 := 获取集群中对象 X 的期望状态
if 实际状态 == 期望状态{
什么都不做
} else {
执行编排动作，将实际状态调整为期望状态
}
}
接下来，以 Deployment 为例，简单描述一下它对控制器模型的实现：
- Deployment 控制器从 Etcd 中获取到所有携带了“app: nginx”标签的 Pod，然后统计它们 的数量，这就是实际状态；
- Deployment 对象的 Replicas 字段的值就是期望状态；
- Deployment 控制器将两个状态做比较，然后根据比较结果，确定是创建 Pod，还是删除已有 的 Pod（具体如何操作 Pod 对象，我会在下一篇文章详细介绍）
这个操作，通常被叫作调谐（Reconcile）。这个调谐的过程，则被称作“Reconcile Loop”（调 谐循环）或者“Sync Loop”（同步循环）。
Deployment 这样的一个控制器，实际上都是由上半部分的控制器定义（包括期 望状态），加上下半部分的被控制对象的模板组成的。
这就是为什么，在所有 API 对象的 Metadata 里，都有一个字段叫作 ownerReference，用于保存 当前这个 API 对象的拥有者（Owner）的信息
如何理解水平扩展 / 收缩？
举个例子，如果你更新了 Deployment 的 Pod 模板（比如，修改了容器的镜像），那么 Deployment 就需要遵循一种叫作“滚动更新”（rolling update）的方式，来升级现有的容器。而这个能力的实现，依赖的是 Kubernetes 项目中的一个非常重要的概念（API 对象）： ReplicaSet。
对于一个 Deployment 所管理的 Pod，它的 ownerReference 是谁？
答案：ReplicaSet
具体的实现上，这个 Deployment，与 ReplicaSet，以及 Pod 的关系是怎样的呢？
把这个值从 3 改成 4，那么 Deployment 所对应的 ReplicaSet，就会根据修改后的值自 动创建一个新的 Pod。这就是“水平扩展”了；“水平收缩”则反之。
kubectl scale deployment nginx-deployment --replicas=4
“滚动更新”又是什么意思，是如何实现的呢？
