【Kubernetes|Kubernetes Deployment 源码分析（一）】概述Deployment 基础创建 DeploymentReplicaSet滚动更新失败回滚历史版本回滚其他特性小结
概述 Deployment 是最常用的 Kubernetes 原生 Workload 资源之一，我们一开始尝试使用 Kubernetes 的时候大概率就是从运行一个 Deployment 类型的工作负载开始的。今天开始我们计划分成几讲来从 Deployment 的特性介绍、源码分析等方面深度剖析 Deployment 资源和其背后的 Deployment 控制器。
Deployment 的基础特性大家基本都熟悉，所以本文我们不计划赘述 Deployment 的所有功能细节，而是从滚动更新等不算太基础的特性入手，看下 Deployment 支持哪些玩法，为后面分析源码做准备。
Deployment 基础 我们创建一个简单的 Deployment，然后看下一些小细节。
创建 Deployment
以运行 nginx 为例，我们可以通过 Deployment 来拉起一个 3 副本的 nginx 负载：nginx-dp

• nginx-dp.yaml

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4name: nginx-dp
5labels:
6app: nginx
7spec:
8replicas: 3
9selector:
10matchLabels:
11app: nginx
12template:
13metadata:
14labels:
15app: nginx
16spec:
17containers:
18- name: nginx
19image: nginx:1.14.2
20ports:
21- containerPort: 80


通过 kubectl create -f nginx-dp.yaml 我们可以创建这个 Deployment 资源。

1# kubectl create -f nginx-dp.yaml
2deployment.apps/nginx-dp created
3# kubectl get deploy
4NAMEREADYUP-TO-DATEAVAILABLEAGE
5nginx-dp1/3313s
6# kubectl get deploy
7NAMEREADYUP-TO-DATEAVAILABLEAGE
8nginx-dp3/33310s


等一会，就可以通过 kubectl get deploy 命令看到所有 Pod 都起来了，这里关注下输出字段含义（NAME 和 AGE 就不用说了）：

• UP-TO-DATE：多少副本已经更新到期望状态了
• AVAILABLE：多少副本已经可以提供服务了
• READY：可以提供服务的副本数/期望副本数

ReplicaSet

• 查询 ReplicaSet

1# kubectl get rs --selector=app=nginx
2NAMEDESIREDCURRENTREADYAGE
3nginx-dp-66b6c48dd53339m54s


前面创建了 Deployment 之后可以看到集群里多了一个 ReplicaSet 资源，也就是说 Deployment 管理的其实是 ReplicaSet 而不是直接管理 Pod，我们继续看下这个 ReplicaSet 的定义来验证下这个想法：

1# kubectl get rs nginx-dp-66b6c48dd5 -o yaml
2apiVersion: apps/v1
3kind: ReplicaSet
4// ……
5ownerReferences:
6- apiVersion: apps/v1
7blockOwnerDeletion: true
8controller: true
9kind: Deployment
10name: nginx-dp
11uid: 97736b65-0171-4916-bb18-feccc343ac14
12resourceVersion: "1099157"
13uid: 83ac5660-28eb-4d40-beb1-cb5ceb6928b6
14// ……


这里可以看到这个 ReplicaSet 属于 Deployment 类型的 nginx-dp 资源。同样的方法可以看到对应 Pod 是属于 ReplicaSet 管理的。
到这里，我们可以猜下 Deployment Controller 的实现原理，大概可以想到其通过管理 ReplicaSet 的生命周期，借助 ReplicaSet Controller 提供的能力间接完成了 Pod 生命周期的管理；另外可以通过创建多个 ReplicaSet 资源，控制其副本数来实现滚动更新和回滚等操作。这样 Deployment Controller 的实现逻辑就相对“高层”了。
滚动更新

• 通过 kubectl set 命令来更新镜像：

1# kubectl set image deployment/nginx-dp nginx=nginx:1.16.1
2deployment.apps/nginx-dp image updated


• 查看 Event

1# kubectl describe deploy nginx-dp
2// ……
3
4Events:
5TypeReasonAgeFromMessage
6-------------------------
7NormalScalingReplicaSet26mdeployment-controllerScaled up replica set nginx-dp-66b6c48dd5 to 3
8NormalScalingReplicaSet88sdeployment-controllerScaled up replica set nginx-dp-559d658b74 to 1
9NormalScalingReplicaSet87sdeployment-controllerScaled down replica set nginx-dp-66b6c48dd5 to 2
10NormalScalingReplicaSet87sdeployment-controllerScaled up replica set nginx-dp-559d658b74 to 2
11NormalScalingReplicaSet86sdeployment-controllerScaled down replica set nginx-dp-66b6c48dd5 to 1
12NormalScalingReplicaSet86sdeployment-controllerScaled up replica set nginx-dp-559d658b74 to 3
13NormalScalingReplicaSet84sdeployment-controllerScaled down replica set nginx-dp-66b6c48dd5 to 0


从 Event 里可以看到 deployment-controller 通过调整 ReplicaSet 资源 nginx-dp-66b6c48dd5 和 nginx-dp-559d658b74 的副本数完成了这次滚动更新，先看下这两个 ReplicaSet：

1# kubectl get rs --selector=app=nginx
2NAMEDESIREDCURRENTREADYAGE
3nginx-dp-559d658b74333134m
4nginx-dp-66b6c48dd5000159m


可以看到这时候新增了一个 nginx-dp-559d658b74，副本数是 3，同时老的 nginx-dp-66b6c48dd5 变成了 0 副本。这个过程大概是这样：

1. nginx-dp-66b6c48dd5 to 3 / replica set nginx-dp-559d658b74 to 1 -> 新 rs 增加一个副本到 1；合计 4 副本
2. Scaled down replica set nginx-dp-66b6c48dd5 to 2 -> 老 rs 减少一个副本到 2；合计 3 副本
3. Scaled up replica set nginx-dp-559d658b74 to 2 -> 新 rs 增加一个副本到 2；合计 4 副本
4. Scaled down replica set nginx-dp-66b6c48dd5 to 1 -> 老 rs 减少一个副本到 1；合计 3 副本
5. Scaled up replica set nginx-dp-559d658b74 to 3 -> 新 rs 增加一个副本到 3；合计 4 副本
6. Scaled down replica set nginx-dp-66b6c48dd5 to 0 -> 老 rs 减少一个副本到 0；合计 3 副本

失败回滚 历史版本
先看下怎么查询更新历史：

1# kubectl rollout history deployments/nginx-dp
2deployment.apps/nginx-dp
3REVISIONCHANGE-CAUSE
41
52


这里可以看到一个细节，CHANGE-CAUSE 是空的，这个字段其实是从 kubernetes.io/change-cause 注解中拿的，我们加个注解试一下：

1kubectl annotate deployment/nginx-dp kubernetes.io/change-cause="image updated to 1.16.1"


再查一次：

1# kubectl rollout history deployments/nginx-dp
2deployment.apps/nginx-dp
3REVISIONCHANGE-CAUSE
41
52image updated to 1.16.1


第一个版本怎么办呢？这里大概可以猜到要存储多个版本的 CHANGE-CAUSE 信息，这个注解应该是用的 ReplicaSet 里的，所以我们尝试这样补充第一个版本的注解：

1kubectl annotate rs/nginx-dp-66b6c48dd5 kubernetes.io/change-cause="nginx deployment created"


再查一次：

1# kubectl rollout history deployments/nginx-dp
2deployment.apps/nginx-dp
3REVISIONCHANGE-CAUSE
41nginx deployment created
52image updated to 1.16.1


现在就比较和谐了，需要指定版本回滚的时候不迷路。
回滚

• 设置一个不存在的镜像版本来模拟更新失败场景：

1# kubectl set image deployment/nginx-dp nginx=nginx:1.161
2deployment.apps/nginx-dp image updated
3# kubectl get rs --selector=app=nginx
4NAMEDESIREDCURRENTREADYAGE
5nginx-dp-559d658b74333168m
6nginx-dp-66b6c48dd50003h13m
7nginx-dp-66bc5d6c81106s
8# kubectl get pod --selector=app=nginx
9NAMEREADYSTATUSRESTARTSAGE
10nginx-dp-559d658b74-l4bq71/1Running0170m
11nginx-dp-559d658b74-qhh8m1/1Running0170m
12nginx-dp-559d658b74-vbtl51/1Running0170m
13nginx-dp-66bc5d6c8-tl8480/1ImagePullBackOff02m2s


• 设置个注解：

1# kubectl annotate deployment/nginx-dp kubernetes.io/change-cause="image updated to 1.161"
2deployment.apps/nginx-dp annotated
3# kubectl rollout history deployments/nginx-dp
4deployment.apps/nginx-dp
5REVISIONCHANGE-CAUSE
61nginx deployment created
72image updated to 1.16.1
83image updated to 1.161


• 回滚到 revision 2：

1# kubectl rollout undo deployment/nginx-dp
2deployment.apps/nginx-dp rolled back
3# kubectl rollout history deployments/nginx-dp
4deployment.apps/nginx-dp
5REVISIONCHANGE-CAUSE
61nginx deployment created
73image updated to 1.161
84image updated to 1.16.1


这时候版本 2 变成了最新的版本：4

• 查看某个版本的详细配置：

1# kubectl rollout history deployments/nginx-dp --revision=1
2deployment.apps/nginx-dp with revision #1
3Pod Template:
4Labels:app=nginx
5pod-template-hash=66b6c48dd5
6Annotations:kubernetes.io/change-cause: nginx deployment created
7Containers:
8nginx:
9Image:nginx:1.14.2
10Port:80/TCP
11Host Port:0/TCP
12Environment:
13Mounts:
14Volumes:


• 指定版本回滚：

1# kubectl rollout undo deployment/nginx-dp --to-revision=1
2deployment.apps/nginx-dp rolled back
3# kubectl rollout history deployments/nginx-dp
4deployment.apps/nginx-dp
5REVISIONCHANGE-CAUSE
63image updated to 1.161
74image updated to 1.16.1
85nginx deployment created


其他特性 最后我们看下 Deployment 类型 spec 的全部属性：

• minReadySeconds：默认值为 0，表示一个 pod reday 之后多长时间可以提供服务；换句话说配置成1就是 pod ready 之后 1s 才对外提供服务；
• paused：挂起；
• progressDeadlineSeconds：默认 600，表示处理一个 Deployment 任务的超时时间，比如 10 分钟到了还没有升级成功，则标记为 failed 状态；
• replicas：副本数；
• revisionHistoryLimit：默认是 10，表示保留的历史版本数量；
• selector：标签选择器；
• strategy：表示 Deployment 更新 pod 时的替换策略；
• template：Pod 模板；

这里的 strategy 有两个属性，分别是：type 和 rollingUpdate。type 可选值是："Recreate" 和 "RollingUpdate"，默认为 "RollingUpdate"。strategy.rollingUpdate 有两个属性：

• maxSurge： 表示滚动更新的时候最多可以比期望副本数多几个，数字或者百分比配置都行；比如 1 表示更新过程中最多同时新增 1 个副本，然后等一个老副本删掉之后才能继续增加 1 个新副本；百分比计算的时候向上取整；
• maxUnavailable：表示滚动更新的时候可以有多少副本不可用，同样是数字或者百分比配置；比如期望副本数是 3，1 则表示最多删除副本到剩下 2，然后要等新副本创建才能继续删除；百分比计算的时候向下取整；

小结 本文我们的目的是知道 Deployment 的全部特性，进而为后面的源码分析做准备。在这个过程中我们没有赘述 Deployment 的基础特性，而是主要介绍“滚动更新”和“回滚”等主要功能，另外简单过一下 Deployment 的 spec 包含的全量配置项，从而心中有个概念，知道 Deployment 的能力边界在那里，从而后面看源码时更有针对性。
（转载请保留本文原始链接 https://www.danielhu.cn）

文章图片

推荐阅读

• 

  尼康3400值得入手吗 尼康340价格
• 

  中医四诊室 中医堂怎么样
• 

  运动励志币计划
• 

  打新冠加强针不满48小时核酸会阳性吗
• 

  河南赊刀人最新预言2021 赊刀人2021年10月前兑现
• 

  匆匆那些年
• 

  遇到博世冰箱显示横杠怎么办？3个处理方法帮助你
• 

  电脑hdmi接口没有反应解决方法
• 

  win10系统与安卓系统,安装手机驱动程序需要注意什么?
• 

  芥菜种植最佳时间和方法及注意事项图片 芥菜种植最佳时间和方法及注意事项
• 

  电饭煲内胆涂层有划痕还能用吗 电饭煲内胆涂层有划痕还能用吗视频
• 

  姓氏来源 姓氏来源查询表
• 

  甲状腺结节忌食哪些食物
• 

  店面部分转租没有经过房东同意转租犯法吗？
• 

  玉米秃尖怎么办 如何防治玉米秃尖
• 

  mla-tl10是什么型号mla-tl10型号是什么
• 

  老人失眠怎么办：6招还你好睡眠
• 

  md788zp/a是什么型号 md788zp/a的型号是什么
• 

  比亚迪f3水温正常不过沒有热风 17年比亚迪f3有时候水温高有时候不高
• 

  达尔文进化岛新手攻略,达尔文进化岛若何举行搭配

• Android事件传递源码分析
• federation--kubernetes集群联邦的实现
• Quartz|Quartz 源码解析(四) —— QuartzScheduler和Listener事件监听
• [源码解析]|[源码解析] NVIDIA HugeCTR，GPU版本参数服务器---(3)
• ffmpeg源码分析01（结构体）
• Java程序员阅读源码的小技巧，原来大牛都是这样读的，赶紧看看！
• Vue源码分析—响应式原理(二)
• SwiftUI|SwiftUI iOS 瀑布流组件之仿CollectionView不规则图文混合(教程含源码)
• java|java b2b2c shop 多用户商城系统源码- config 修改配置
• Spring源码解析_属性赋值