应用编排与管理：Deployment

背景问题
如果直接管理Pod，那么每个应用的Pod是散乱的分布在集群中的

需要解决的问题：
1. 如何保证集群内可用的Pod数量
2. 如何为所有的Pod更新镜像版本
3. 更新的过程中，如何保证服务的可用性
4. 更新的过程中，发现问题如何快速回滚

Deployment: 管理部署发布的控制器

Deployment的作用：
1. 定义一组Pod的期望数量，controller会维持Pod数量与期望数量一致
2. 配置Pod发布方式，controller会按照给定策略更新Pod，保证更新过程中不可用的Pod数量在限定范围内
3. 如果发布有问题，支持一键回滚

Deployment语法：
apiVersion：比如 apps/v1，表示当前所属组为apps，版本是v1
metadata：元信息，常见的比如labels，name，namespace
replicas:：终态数量
template：pod模板
labels：标签
selector：选择器
pod image：镜像版本

Deployment状态：

kubectl get deployment -o wide |grep nginx

NAME          READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS IMAGES SELECTOR
nginx-deploy  3/3     3            3           10d    nginx     nginx  app=nginx

NAME： deployment名称
READY： 未ready数量/期望ready数量
UP-TO-DATE：到达期望版本的pod数量
AVAILABLE：运行中并可用的pod数量
AGE：deployment创建的时长
CONTAINERS：容器名称
IMAGES：镜像名称
SELECTOR：选择器

查看Pod：

kubectl get pod

NAME                            READY       STATUS             RESTARTS   AGE
nginx-deploy-7848d4b86f-fz8tf   1/1         Running            0          10d
nginx-deploy-7848d4b86f-rbqp6   1/1         Running            0          10d
nginx-deploy-7848d4b86f-wvbxc   1/1         Running            0          10d

pod名字格式：${deployment-name}-${template-hash}-${random-suffix}

更新镜像

kubectl set image deployment.v1.apps/nginx-deploy nginx=nginx:1.9.1

kubectl set image：固定写法
deployment.v1.apps：也是固定写法，deployment表示资源类型，v1表示资源版本，apps表示资源组。也可简写为deployment或deployment.apps，比如写deployment的时候，默认将使用apps组的v1版本。
nginx-deploy：表示资源名称
nginx=nginx:1.9.1：表示这个容器所希望更新的镜像

快速回滚：
回滚到Deployment上一个版本：

kubectl rollout undo deployment/nginx-deploy

回滚到Deployment到某一个版本，需要先查询版本列表：

kubectl rollout history deployment/nginx-deploy

然后回滚：

kubectl rollout undo deployment.v1.apps/nginx-deploy --to-revision=2

DeploymentStatus：

Processing：Deployment正在扩容和发布中，当Processing状态的deployment，它所有的replicas及Pod副本全部达到最新版本，
而且是available，这样就可以进入complete状态，complete状态如果发生了一些扩容缩容的话，也会进入processing这个处理工作状态。
Failed：如果处理过程中出现问题，比如拉取镜像失败，或者readiness probe检查失败，就会进入failed状态，如果在运行过程中即complete状态，中间运行时发生了一些pod readiness probe检查失败，也会进入failed状态，进入failed状态之后，除非所有replicas均变成available，而且是updated最新版本，deployment才会重新进入complete状态。
Complete：正常运行中

架构设计-管理模式：

Deployment只负责管理不同版本的ReplicaSet，由ReplicaSet管理Pod副本数
每个ReplicaSet对应了Deployment template的一个版本
一个ReplicaSet下的Pod都是相同的版本

Deployment控制器：

所有的控制器都是通过 Informer 中的 Event 做一些 Handler 和 Watch。
通过监听Deployment 和 ReplicaSet 中的 event，收到事件后会Check Paused，表示是否需要新的发布，如果Paused设置为true的话，就表示该deployment
只需要维持数量，不用做新的发布；如果 paused 为 false ，就会做 Rollout，通过 Create 或者Rolling 的方式来做更新，更新的方式是通过 Create/Update/Delete 这种 ReplicaSet 来实现。 

ReplicaSet 控制器：

当Deployment分配ReplicaSet之后，ReplicaSet 控制器本身也是从 Informer 中 watch 一些事件，这些事件包含了 ReplicaSet 和 Pod 的事件。从队列中取出之后，ReplicaSet controller 的逻辑很简单，就只管理副本数。也就是说如果 controller 发现 replicas 比 Pod 数量大的话，就会扩容，而如果发现实际数量超过期望数量的话，就会删除 Pod。
Deployment 控制器做了更复杂的事情，包含了版本管理，而它把每一个版本下的数量维持工作交给 ReplicaSet 来做 

deployment.spec字段解析
MinReadySeconds：Deployment 会根据 Pod ready 来看 Pod 是否可用，但是如果我们设置了 MinReadySeconds 之后，比如设置为 30 秒，那 Deployment 就会等到 Pod ready 超过 30 秒之后才认为 Pod 是 available 的。Pod available 的前提条件是 Pod ready，但是 ready 的 Pod 不一定是 available 的，它一定要超过 MinReadySeconds 之后，才会判断为 available；

revisionHistoryLimit：保留历史 revision，即保留历史 ReplicaSet 的数量，默认值为 10 个。这里可以设置为一个或两个，如果回滚可能性比较大的话，可以设置数量超过 10；

paused：paused 是标识Deployment 只做数量维持，不做新的发布；
progressDeadlineSeconds：当 Deployment 处于扩容或者发布状态时，它的 condition 会处于一个 processing 的状态，processing 可以设置一个超时时间。如果超过超时时间还处于processing，那么 controller 将认为这个 Pod 会进入 failed 的状态。

MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；
MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量。
MaxSurge 和 MaxUnavailable 不能同时为 0。

标签：版本,ReplicaSet,Deployment,nginx,编排,应用,deployment,Pod
来源： https://blog.csdn.net/weixin_42758299/article/details/119332669