首页分享 Pod控制器Deployment使用详解（更新策略、回滚策略、暂停策略）以及金丝雀发布详解

Pod控制器Deployment使用详解（更新策略、回滚策略、暂停策略）以及金丝雀发布详解

来源：花匠小妙招时间：2024-12-30 00:38

文章目录 Deployment更新策略升级策略关于金丝雀发布扩展知识发布规则发布流程回滚策略暂停策略

需要注意：
在学习kubernetes时需要高清RC和deployment两着各自的不同点。
官方建议使用Deployment管理ReplicaSets，而不是直接使用ReplicaSet，这就意味着可能永远不需要直接操作ReplicaSet对象，因此Deployment将会是使用最频繁的资源对象。
在这里插入图片描述
创建deploy

apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deployment labels: app: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - containerPort: 80 name: http

12345678910111213141516171819202122

Deployment

更新策略

使用RS或者RC控制器需要手动分成多步去更新，过程繁杂且容易出错，而deployment却只需要由用户指定在Pod模板中要更改的内容，例如容器镜像的版本，余下的步骤可以自动完成。同时更新规模也需要修改为期望的副本数量，余下的事情交给deployment即可。
deployment控制器的详细信息中包含了其跟更新策略的相关配置信息。使用describe即可查看，如下：

[root@master redis-demo]# kubectl get deploy -A NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE ingress-nginx nginx-ingress-controller 1/1 1 1 8d kube-system coredns 2/2 2 2 21d 1234

使用describe查看到输出的命令中包含：
strategytype
RollingupdateStrategy
等字段

[root@master redis-demo]# kubectl describe deploy nginx-ingress-controller -n ingress-nginx Name: nginx-ingress-controller Namespace: ingress-nginx CreationTimestamp: Mon, 02 Dec 2019 17:55:50 +0800 Labels: app.kubernetes.io/name=ingress-nginx app.kubernetes.io/part-of=ingress-nginx Annotations: deployment.kubernetes.io/revision: 1 Selector: app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app.kubernetes.io/name=ingress-nginx app.kubernetes.io/part-of=ingress-nginx Annotations: prometheus.io/port: 10254 prometheus.io/scrape: true Service Account: nginx-ingress-serviceaccount Containers: nginx-ingress-controller: Image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1 Ports: 80/TCP, 443/TCP Host Ports: 0/TCP, 0/TCP Args: /nginx-ingress-controller --configmap=$(POD_NAMESPACE)/nginx-configuration --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services --udp-services-configmap=$(POD_NAMESPACE)/udp-services --publish-service=$(POD_NAMESPACE)/ingress-nginx --annotations-prefix=nginx.ingress.kubernetes.io Liveness: http-get http://:10254/healthz delay=10s timeout=10s period=10s #success=1 #failure=3 Readiness: http-get http://:10254/healthz delay=0s timeout=10s period=10s #success=1 #failure=3 Environment: POD_NAME: (v1:metadata.name) POD_NAMESPACE: (v1:metadata.namespace) Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Progressing True NewReplicaSetAvailable Available True MinimumReplicasAvailable OldReplicaSets: <none> NewReplicaSet: nginx-ingress-controller-688987f6c9 (1/1 replicas created) Events: <none> [root@master redis-demo]#

12345678910111213141516171819202122232425262728293031323334353637383940414243444546

Deployment控制器支持两种更新策略：滚动更新（rolling updata）和重新构建（recreate），默认情况下为滚动更新。重新创建为：先删除所有的Pod再根据新的模板创建新的Pod，中间会导致服务的不可用，用户要么使用的是新版本，要么就是旧版本。
滚动升级是默认的更新策略，它在删除一些旧版本的Pod的同时补充创建一些新的Pod，更新期间服务不会中断。
滚动更新期间，应用升级期间还要确保可用的Pod对象数量不低于某些阈值。，确保可以持续处理客户端请求。变动的方式和Pod对象的数量范围将通过==spec.strategy.roollingUpdata.maxSurge和spec.strategy.roollingUpdata.maxunavailable两个属性协同进行定义。两个参数用法如下：

maxSurge：指定升级期间存在的总Pod对象数量最多以超出期望值的个数，其值可以为0或者正整数，也可以是一个期望值的百分比：例如如果期望值是3，当前的属性值为1，则表示Pod对象的总数不能超过4个。maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望的个数、其值可以是0或者正整数。也可以是一个期望值的百分比，默认值为1；该值意味着如果期望值是3，那么在升级期间至少要有两个Pod对象处于正常提供服务的状态。

maxSurge和maxUnavailable的数量不能同时为0，否则Pod对象的复本数量在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。

配置时，用户还可以使用 Deployment控制器的 spec.min.Ready.Seconds属性来控制应用升级的速度。新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被视作可用，而后即可立即开始下一轮的替换操作。而 spec.minReady.Seconds能够定义在新的Pod对象创建后至少要等待多久才会将其视作就绪，在此期间，更新操作会被阻塞。因此，它可以用来让 Kubernetes在每次创建出Pod资源后都要等上一段时长后再开始下一轮的更替，这个时间长度的理想值是等到Pod对象中的应用已经可以接受并处理请求流量。事实上，一个精心设计的等待时长和就绪性探测能让 Kubernetes系统规避一部分因程序Bug而导致的升级故障。
Deployment控制器也支持用户保留其滚动更新历史中的旧 Replicase对象版本，如
图5-10所示，这赋予了控制器进行应用回滚的能力:用户可按需回滚到指定的历史版本。
控制器可保存的历史版本数量由“ spec revision History Limit”属性进行定义。当然，也只有保存于 revision历史中的 Replicase版本可用于回滚，因此，用户要习惯性地在更新操作时指定保留旧版本。

为了在保存版本升级的历史，需要在创建deployment对象时在命令中使用"–record"选项

尽管滚动更新以节约系统资源著称，但它也存在一些劣势。直接改动现有环境，会使系统引入不确定性风险，而且升级过程出现问题后，执行回滚操作也会较为缓慢。有鉴于此，金丝雀部署可能是较为理想的实现方式，当然，如果不考虑系统资源的可用性，那么传统的蓝绿部署也是不错的选择。

升级策略

修改Pod模板相关的配置参数便能完成 Deployment控制器资源的更新。由于是声明式配置，因此对 Deployment控制器资源的修改尤其适合使用 apply和 patch命令来进行;当然，如果仅是修改容器镜像，“ set image”命令更为易用。
创建Pod

[root@master nginx-demo]# kubectl get pods NAME READY STATUS RESTARTS AGE myapp-deployment-869b99788d-fp74z 1/1 Running 0 29s myapp-deployment-869b99788d-jddnr 1/1 Running 0 29s myapp-deployment-869b99788d-qkqmt 1/1 Running 0 29s 12345

接下来通过更新此前创建的 Deployment控制器 deploy-example来了解更新操作过程的执行细节，为了使得升级过程更易于观测，这里先使用“ kubectl patch”命令为其specmin Ready Seconds字段定义一个等待时长，例如8s:
修改配置，更换镜像

[root@master nginx-demo]# kubectl patch deployments myapp-deployment -p '{"spec":{"minReadySeconds":8}}' deployment.extensions/myapp-deployment patched (change) [root@master nginx-demo]# kubectl set image deployments myapp-deployment myapp=ikubernetes/myapp:v2 deployment.extensions/myapp-deployment image updated 1234

patch命令的补丁形式为Json格式，以-p选项指定，上面命令中的’{“spec”:{“minReadySeconds”:8}}‘表示设置spec.minReady.Seconds属性的值。若要改变 myapp- deploy中 myapp容器的镜像，也可使用 patch命令，如’{“spec”: {“contianers”: [“name”: “myapp”,“image”“ikubernetes/myapp: v2”]}}’，不过修改容器镜像有更加简单的专有命令‘set image’
查看状态

[root@master nginx-demo]# kubectl rollout status deployments myapp-deployment Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "myapp-deployment" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "myapp-deployment" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "myapp-deployment" rollout to finish: 1 old replicas are pending termination... deployment "myapp-deployment" successfully rolled out [root@master nginx-demo]# kubectl get deployments myapp-deployment --watch NAME READY UP-TO-DATE AVAILABLE AGE myapp-deployment 3/3 3 3 9m44s 1234567891011

滚动更新时， myapp-deploy控制器会创建一个新的 ReplicaSe控制器对象来管控新版
本的Pod对象，升级完成后，旧版本的 Replicase会保留在历史记录中，但其此前的管控
Pod对象将会被删除。

[root@master nginx-demo]# kubectl get replicasets -l app=myapp NAME DESIRED CURRENT READY AGE myapp-deployment-7c5bf99bbf 3 3 3 100s myapp-deployment-869b99788d 0 0 0 10m [root@master nginx-demo]# kubectl get pods -l app=myapp NAME READY STATUS RESTARTS AGE myapp-deployment-7c5bf99bbf-jkktz 1/1 Running 0 96s myapp-deployment-7c5bf99bbf-skpbn 1/1 Running 0 115s myapp-deployment-7c5bf99bbf-zxhx7 1/1 Running 0 2m14s 12345678910

测试显示已经更换了版本v2

[root@master nginx-demo]# curl $(kubectl get pods myapp-deployment-7c5bf99bbf-jkktz -o go-template={{.status.podIP}}) Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a> 12 关于金丝雀发布扩展知识

矿井中的金丝雀
17世纪，英国工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯气体，金丝雀也会停止歌唱；当瓦斯含量查过一定限度时，人类依然毫无察觉，而金丝雀却早已毒发身亡。当时在采矿设备相对简陋的情况下，工人们每次下井都会带上一直金丝雀作为瓦斯检测工具，以便在危险状况下紧急撤离。

发布规则

在更新时执行暂停操作，通过Service或Ingress资源和相关的路由策略将部分用户的请求流量引入到这些新的Pod之上进行发布验证，运行一段时间后，如果确定没有问题，即可使用kubectl roollout resume"命令继续滚动更新过程。

发布流程