# Kubernetes 通过引入 Controller（控制器）的概念来管理 Pod 实例
在 Kubernetes 中，您应该始终通过创建 Controller 来创建 Pod，而不是直接创建 Pod。控制器可以提供如下特性：
水平扩展（运行 Pod 的多个副本）
rollout（版本更新）
self-healing（故障恢复） 例如：当一个节点出现故障，控制器可以自动地在另一个节点调度一个配置完全一样的 Pod，以替换故障节点上的 Pod。
在 Kubernetes 支持的控制器有如下几种：
1. Deployment
Deployment 是最常用的用于部署无状态服务的方式。Deployment 控制器使得您能够以声明的方式更新 Pod（容器组）和 ReplicaSet（副本集）。
1.1 创建
---执行命令以创建 Deployment
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
---检查 Deployment 的创建情况
kubectl get deployments
---查看 Deployment 的发布状态
kubectl rollout status deployment.v1.apps/nginx-deployment
---此时该 Deployment 已经完成了 3 个 Pod 副本的创建，并且所有的副本都是 UP-TO-DATE（符合最新的 Pod template 定义） 和 AVAILABEL
kubectl get deployments
---查看该 Deployment 创建的 ReplicaSet（rs）
kubectl get rs
---查看 Pod 的标签
kubectl get pods --show-labels
字段含义
字段名称 说明
NAME Deployment name
DESIRED Deployment 期望的 Pod 副本数，即 Deployment 中 .spec.replicas 字段指定的数值。该数值是“期望”值
CURRENT 当前有多少个 Pod 副本数在运行
UP-TO-DATE Deployment 中，符合当前 Pod Template 定义的 Pod 数量
AVAILABLE 当前对用户可用的 Pod 副本数
AGE Deployment 部署以来到现在的时长
您必须为 Deployment 中的 .spec.selector 和 .template.metadata.labels 定义一个合适的标签（这个例子中的标签是 app: nginx）。请不要使用与任何其他控制器（其他 Deployment / StatefulSet 等）相同的 .spec.selector 和 .template.metadata.labels。否则可能发生冲突，并产生不可预见的行为。
在这个例子中：
将创建一个名为 nginx-deployment 的 Deployment（部署），名称由 .metadata.name 字段指定
该 Deployment 将创建 3 个 Pod 副本，副本数量由 .spec.replicas 字段指定
.spec.selector 字段指定了 Deployment 如何找到由它管理的 Pod。此案例中，我们使用了 Pod template 中定义的一个标签（app: nginx）。对于极少数的情况，这个字段也可以定义更加复杂的规则
.template 字段包含了如下字段：
.template.metadata.labels 字段，指定了 Pod 的标签（app: nginx）
.template.spec.containers[].image 字段，表明该 Pod 运行一个容器 nginx:1.7.9
.template.spec.containers[].name 字段，表明该容器的名字是 nginx
1.2 更新
---执行以下命令，将容器镜像从 nginx:1.7.9 更新到 nginx:1.9.1
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
-输出结果如下所示：
deployment.apps/nginx-deployment image updated
---或者，您可以 edit 该 Deployment，并将 .spec.template.spec.containers[0].image 从 nginx:1.7.9 修改为 nginx:1.9.1
kubectl edit deployment.v1.apps/nginx-deployment
-输出结果如下所示
deployment.apps/nginx-deployment edited
---查看发布更新（rollout）的状态，执行命令：
kubectl rollout status deployment.v1.apps/nginx-deployment
1.3 回滚
---假设您在更新 Deployment 的时候，犯了一个拼写错误，将 nginx:1.9.1 写成了 nginx:1.91
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
---检查 Deployment 的更新历史
kubectl rollout history deployment.v1.apps/nginx-deployment
---查看 revision（版本）的详细信息
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
---将当前版本回滚到前一个版本
kubectl rollout undo deployment.v1.apps/nginx-deployment
---您也可以使用 --to-revision 选项回滚到前面的某一个指定版本
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
---检查该回滚是否成功
kubectl get deployment nginx-deployment
---查看 Deployment 的详情
kubectl describe deployment nginx-deployment
1.4 伸缩
kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
---如果您的集群启用了自动伸缩（horizontal Pod autoscaling (opens new window)），执行以下命令，您就可以基于 CPU 的利用率在一个最大和最小的区间自动伸缩您的 Deployment：
kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
---查看 Deployment 的情况
kubectl get deployment
---查看 ReplicaSet 的情况
kubectl get rs
1.5 暂停
kubectl rollout pause deployment.v1.apps/nginx-deployment
---更新 Deployment 的容器镜像
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
-deployment.apps/nginx-deployment image updated
---如果需要的话，您可以针对 Deployment 执行更多的修改
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
-deployment.apps/nginx-deployment resource requirements updated
---确保 Deployment 的信息已被正确修改
kubectl describe deployment nginx-deployment
---暂停 Deployment 之前的信息当前仍然在起作用，而暂停 Deployment 之后，修改的 Deployment 信息尚未生效，因为该 Deployment 被暂停了。
---继续（resume）该 Deployment，可使前面所有的变更一次性生效
kubectl rollout resume deployment.v1.apps/nginx-deployment
---观察滚动更新的进展
kubectl get rs -w
---查看 ResultSet 的最终状态
kubectl get rs
您不能回滚（rollback）一个已暂停的 Deployment，除非您继续（resume）该 Deployment。
1.6 状态
---监控 Deployment 滚动更新的过程
kubectl rollout status deployment.v1.apps/nginx-deployment
1.7 清理策略
---通过 Deployment 中 .spec.revisionHistoryLimit 字段，可指定为该 Deployment 保留多少个旧的 ReplicaSet。超出该数字的将被在后台进行垃圾回收。该字段的默认值是 10。
---如果该字段被设为 0，Kubernetes 将清理掉该 Deployment 的所有历史版本（revision），因此，您将无法对该 Deployment 执行回滚操作 kubectl rollout undo。
1.8 部署策略
---通过 Deployment 中 .spec.strategy 字段，可以指定使用 滚动更新 RollingUpdate 的部署策略还是使用 重新创建 Recreate 的部署策略
其中字段的含义如下：
| 字段名称 | 可选值 | 字段描述 |
|---|
| 类型 | 滚动更新
重新创建 | 如果选择重新创建，Deployment将先删除原有副本集中的所有 Pod，然后再创建新的副本集和新的 Pod。如此，更新过程中将出现一段应用程序不可用的情况； |
| 最大超出副本数 | 数字或百分比 | 滚动更新过程中，可以超出期望副本数的最大值。
该取值可以是一个绝对值（例如：5），也可以是一个相对于期望副本数的百分比（例如：10%）；
如果填写百分比，则以期望副本数乘以该百分比后向上取整的方式计算对应的绝对值；
当最大超出副本数 maxUnavailable 为 0 时，此数值不能为 0；默认值为 25%。
例如：假设此值被设定为 30%，当滚动更新开始时，新的副本集（ReplicaSet）可以立刻扩容，
但是旧 Pod 和新 Pod 的总数不超过 Deployment 期待副本数（spec.repilcas）的 130%。
一旦旧 Pod 被终止后，新的副本集可以进一步扩容，但是整个滚动更新过程中，新旧 Pod 的总
数不超过 Deployment 期待副本数（spec.repilcas）的 130%。 |
| 最大不可用副本数 | 数字或百分比 | 滚动更新过程中，不可用副本数的最大值。
该取值可以是一个绝对值（例如：5），也可以是一个相对于期望副本数的百分比（例如：10%）；
如果填写百分比，则以期望副本数乘以该百分比后向下取整的方式计算对应的绝对值；
当最大超出副本数 maxSurge 为 0 时，此数值不能为 0；默认值为 25%；
例如：假设此值被设定为 30%，当滚动更新开始时，旧的副本集（ReplicaSet）可以缩容到期望
副本数的 70%；在新副本集扩容的过程中，一旦新的 Pod 已就绪，旧的副本集可以进一步缩容，
整个滚动更新过程中，确保新旧就绪副本数之和不低于期望副本数的 70%。 |
2.StatefulSet
StatefulSet 顾名思义，用于管理 Stateful（有状态）的应用程序。
StatefulSet 管理 Pod 时，确保其 Pod 有一个按顺序增长的 ID。
与 Deployment 相似，StatefulSet 基于一个 Pod 模板管理其 Pod。与 Deployment 最大的不同在于 StatefulSet 始终将一系列不变的名字分配给其 Pod。这些 Pod 从同一个模板创建，但是并不能相互替换：每个 Pod 都对应一个特有的持久化存储标识。
StatefulSet 使用场景
对于有如下要求的应用程序，StatefulSet 非常适用：
稳定、唯一的网络标识（dnsname）
每个Pod始终对应各自的存储路径（PersistantVolumeClaimTemplate）
按顺序地增加副本、减少副本，并在减少副本时执行清理
按顺序自动地执行滚动更新
如果一个应用程序不需要稳定的网络标识，或者不需要按顺序部署、删除、增加副本，您应该考虑使用 Deployment 这类无状态（stateless）的控制器。
3.DaemonSet
DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。
每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
当节点从集群中移除时，Pod 也就被垃圾回收了
删除一个 DaemonSet 可以清理所有由其创建的 Pod
DaemonSet 的典型使用场景有：
在每个节点上运行集群的存储守护进程，例如 glusterd、ceph
在每个节点上运行日志收集守护进程，例如 fluentd、logstash
在每个节点上运行监控守护进程，例如 Prometheus Node Exporter (opens new window)、Sysdig Agent (opens new window)、collectd、Dynatrace OneAgent (opens new window)、APPDynamics Agent (opens new window)、Datadog agent (opens new window)、New Relic agent (opens new window)、Ganglia gmond、Instana Agent (opens new window) 等
通常情况下，一个 DaemonSet 将覆盖所有的节点。复杂一点儿的用法，可能会为某一类守护进程设置多个 DaemonSets，每一个 DaemonSet 针对不同类硬件类型设定不同的内存、cpu请求。
4.Jobs
Kubernetes中的 Job 对象将创建一个或多个 Pod，并确保指定数量的 Pod 可以成功执行到进程正常结束：
当 Job 创建的 Pod 执行成功并正常结束时，Job 将记录成功结束的 Pod 数量
当成功结束的 Pod 达到指定的数量时，Job 将完成执行
删除 Job 对象时，将清理掉由 Job 创建的 Pod
一个简单的例子是：创建一个 Job 对象用来确保一个 Pod 的成功执行并结束。在第一个 Pod 执行失败或者被删除（例如，节点硬件故障或机器重启）的情况下，该 Job 对象将创建一个新的 Pod 以重新执行。
当然，您也可以使用 Job 对象并行执行多个 Pod。
5.CronJob
CronJob 按照预定的时间计划（schedule）创建 Job。一个 CronJob 对象类似于 crontab (cron table) 文件中的一行记录。该对象根据 Cron (opens new window) 格式定义的时间计划，周期性地创建 Job 对象。
Schedule
所有 CronJob 的 schedule 中所定义的时间，都是基于 master 所在时区来进行计算的。
6.ReplicaSet
ReplicaSet的定义中，包含：
selector： 用于指定哪些 Pod 属于该 ReplicaSet 的管辖范围
replicas： 副本数，用于指定该 ReplicaSet 应该维持多少个 Pod 副本
template： Pod模板，在 ReplicaSet 使用 Pod 模板的定义创建新的 Pod
