脚本宝典收集整理的这篇文章主要介绍了Kubernetes Deployment 源码分析(一),脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
@H_360_3@概述deployment 基础创建 DeploymentReplicaSet滚动更新失败回滚历史版本回滚其他特性小结
Deployment@H_777_57@ 是最常用的 Kubernetes 原生 Workload 资源之一,我们一开始尝试使用 Kubernetes 的时候大概率就是从运行一个 Deployment 类型的工作负载开始的。今天开始我们计划分成几讲来从 Deployment 的特性介绍、源码分析等方面深度剖析 Deployment 资源和其背后的 Deployment 控制器。
Deployment 的基础特性大家基本都熟悉,所以本文我们不计划赘述 Deployment 的所有功能细节,而是从滚动更新等不算太基础的特性入手,看下 Deployment 支持哪些玩法,为后面分析源码做准备。
我们创建一个简单的 Deployment,然后看下一些小细节。
以运行 nginx 为例,我们可以通过 Deployment 来拉起一个 3 副本的 nginx 负载:nginx-dp
1apiVersion: apps/v1 2kind: Deployment 3metadata: 4 name: nginx-dp 5 labels: 6 app: nginx 7sPEc: 8 replicas: 3 9 selector:10 matchLabels:11 app: nginx12 template:13 metadata:14 labels:15 app: nginx16 spec:17 containers:18 - name: nginx19 image: nginx:1.14.220 ports:21 - containerPort: 80
通过 kubectl create -f nginx-dp.yaML
我们可以创建这个 Deployment 资源。
1# kubectl create -f nginx-dp.yaml2deployment.apps/nginx-dp created3# kubectl get deploy4NAME READY UP-tO-DATE AVAILABLE AGE5nginx-dp 1/3 3 1 3s6# kubectl get deploy7NAME READY UP-TO-DATE AVAILABLE AGE8nginx-dp 3/3 3 3 10s
等一会,就可以通过 kubectl get deploy
命令看到所有 Pod 都起来了,这里关注下输出字段含义(NAME 和 AGE 就不用说了):
1# kubectl get rs --selector=app=nginx2NAME DESIred current READY AGE3nginx-dp-66b6c48dd5 3 3 3 9m54s
前面创建了 Deployment 之后可以看到集群里多了一个 ReplicaSet 资源,也就是说 Deployment 管理的其实是 ReplicaSet 而不是直接管理 Pod,我们继续看下这个 ReplicaSet 的定义来验证下这个想法:
1# kubectl get rs nginx-dp-66b6c48dd5 -o yaml 2apiVersion: apps/v1 3kind: ReplicaSet 4// …… 5 ownerReferences: 6 - apiVersion: apps/v1 7 blockOwnerDeletion: true 8 controller: true 9 kind: Deployment10 name: nginx-dp11 uid: 97736b65-0171-4916-bb18-feccc343ac1412 resourceVersion: "1099157"13 uid: 83ac5660-28eb-4d40-beb1-cb5ceb6928b614// ……
这里可以看到这个 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.12deployment.apps/nginx-dp image updated
1# kubectl describe deploy nginx-dp 2// …… 3 4Events: 5 Type Reason Age From Message 6 ---- ------ ---- ---- ------- 7 Normal ScalingReplicaSet 26m deployment-controller Scaled up replica set nginx-dp-66b6c48dd5 to 3 8 Normal ScalingReplicaSet 88s deployment-controller Scaled up replica set nginx-dp-559d658b74 to 1 9 Normal ScalingReplicaSet 87s deployment-controller Scaled down replica set nginx-dp-66b6c48dd5 to 210 Normal ScalingReplicaSet 87s deployment-controller Scaled up replica set nginx-dp-559d658b74 to 211 Normal ScalingReplicaSet 86s deployment-controller Scaled down replica set nginx-dp-66b6c48dd5 to 112 Normal ScalingReplicaSet 86s deployment-controller Scaled up replica set nginx-dp-559d658b74 to 313 Normal ScalingReplicaSet 84s deployment-controller Scaled 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=nginx2NAME DESIRED CURRENT READY AGE3nginx-dp-559d658b74 3 3 3 134m4nginx-dp-66b6c48dd5 0 0 0 159m
可以看到这时候新增了一个 nginx-dp-559d658b74,副本数是 3,同时老的 nginx-dp-66b6c48dd5 变成了 0 副本。这个过程大概是这样:
先看下怎么查询更新历史:
1# kubectl rollout history deployments/nginx-dp2deployment.apps/nginx-dp3revISION CHANGE-CAUSE41 <none>52 <none>
这里可以看到一个细节,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-dp2deployment.apps/nginx-dp3REVISION CHANGE-CAUSE41 <none>52 image 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-dp2deployment.apps/nginx-dp3REVISION CHANGE-CAUSE41 nginx deployment created52 image 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 4NAME DESIRED CURRENT READY AGE 5nginx-dp-559d658b74 3 3 3 168m 6nginx-dp-66b6c48dd5 0 0 0 3h13m 7nginx-dp-66bc5d6c8 1 1 0 6s 8# kubectl get pod --selector=app=nginx 9NAME READY statUS RESTARTS AGE10nginx-dp-559d658b74-l4bq7 1/1 Running 0 170m11nginx-dp-559d658b74-qhh8m 1/1 Running 0 170m12nginx-dp-559d658b74-vbtl5 1/1 Running 0 170m13nginx-dp-66bc5d6c8-tl848 0/1 ImagePullBackOff 0 2m2s
1# kubectl annotate deployment/nginx-dp kubernetes.io/change-cause="image updated to 1.161"2deployment.apps/nginx-dp annotated3# kubectl rollout history deployments/nginx-dp4deployment.apps/nginx-dp5REVISION CHANGE-CAUSE61 nginx deployment created72 image updated to 1.16.183 image updated to 1.161
1# kubectl rollout undo deployment/nginx-dp2deployment.apps/nginx-dp rolled back3# kubectl rollout history deployments/nginx-dp4deployment.apps/nginx-dp5REVISION CHANGE-CAUSE61 nginx deployment created73 image updated to 1.16184 image 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: 4 Labels: app=nginx 5 pod-template-hash=66b6c48dd5 6 Annotations: kubernetes.io/change-cause: nginx deployment created 7 Containers: 8 nginx: 9 Image: nginx:1.14.210 Port: 80/TCP11 Host Port: 0/TCP12 environment: <none>13 mounts: <none>14 Volumes: <none>
1# kubectl rollout undo deployment/nginx-dp --to-revision=12deployment.apps/nginx-dp rolled back3# kubectl rollout history deployments/nginx-dp4deployment.apps/nginx-dp5REVISION CHANGE-CAUSE63 image updated to 1.16174 image updated to 1.16.185 nginx deployment created
最后我们看下 Deployment 类型 spec 的全部属性:
这里的 strategy 有两个属性,分别是:type 和 rollingUpdate。type 可选值是:"Recreate" 和 "RollingUpdate",默认为 "RollingUpdate"。strategy.rollingUpdate 有两个属性:
本文我们的目的是知道 Deployment 的全部特性,进而为后面的源码分析做准备。在这个过程中我们没有赘述 Deployment 的基础特性,而是主要介绍“滚动更新”和“回滚”等主要功能,另外简单过一下 Deployment 的 spec 包含的全量配置项,从而心中有个概念,知道 Deployment 的能力边界在那里,从而后面看源码时更有针对性。
(转载请保留本文原始链接 https://www.danielhu.cn)
以上是脚本宝典为你收集整理的Kubernetes Deployment 源码分析(一)全部内容,希望文章能够帮你解决Kubernetes Deployment 源码分析(一)所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。