一、Deployment的参数pc-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: test spec: replicas: 4 #保存历史版本数量 revisionHistoryLimit: 2 #控制滚动更新的速度(秒) minReadySeconds: 0 #标识Deployment只做数量维持、不做新的发布默认值false代表当前deploy可以更新) paused: false strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 0 type: RollingUpdate selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.18revisionHistoryLimitDeployment保留一部分更新历史中旧版本的 ReplicaSet 对象当我们执行回滚操作的时候就直接使用旧版本的ReplicaSet在 Deployment 资源保存历史版本数量有 spec.revisionHistoryLimit 属性进行定义。minReadySecondsDeployment支持使用 spec.minReadySeconds 字段来控制滚动更新的速度默认值为0表示新建的Pod对象-旦“就绪”将立即被视作可用随后即可开始下一轮更新过程如果设定了 spec.minReadySeconds: 3表示新建的Pod对象至少要成功运行多久才会被视作可用即就绪之后还要等待指定的 3s 才能开始下一批次的更新。在一个批次内新建的所有POD就绪后在转为可用状态前更新操作会被阻塞并且任何一个Pod就绪探测失败都会导致滚动更新被终止。因此为minReadySeconds设定一个合理的值不仅能够减缓更新的速度还能够让Deployment提前发现一部分程序因为Bug导致的升级故障。pausedpaused暂停部署默认是false标识Deployment只做数量维持、不做新的发布progressDeadlineSeconds滚动更新故障超时时长默认为600秒k8s 在升级过程中有可能由于各种原因升级卡住(这个时候还没有明确的升级失败)比如在拉取镜像权限不够等错误。如果配置 progressDeadlineSeconds当达到了时间如果还卡着则会上报这个异常情况这个时候这个 Deployment 状态就被标记为 False并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的升级操作。二、Deployment中的灰度发布金丝雀发布)是什么金丝雀发布又名灰度发布)是指在新与旧之间能够精确控制发布流程的一种发布方式在其上可以进行A/B testing即让一部分用户继续用旧产品特性A一部分用户开始用新产品特性B待充分测试验证新产品特性B以后再继续推进发布新版本的pod运行一段时间后如果没有报错那么就可以逐步扩大新版本的pod的数量并逐步完成更新如果新版本的pod运行一段时间后有报错那么就可以快速回退新版本的pod降级为发布之前的老版本A及时止损。K8s中的灰度发布Deployment控制器支持控制更新过程中的控制如“暂停(pause)”或“继续(resume)”更新操作。比如有一批新的Pod资源创建完成后立即暂停更新过程此时仅存在一部分新版本的应用主体部分还是旧的版本。然后再筛选一小部分的用户请求路由到新版本的Pod应用继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新否则立即回滚更新操作。这就是所谓的金丝雀发布。pc-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: test spec: replicas: 4 #滚动更新 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 0 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.18让deployment升级并立刻暂停# 更新deployment的版本第一轮迭代升级之后并立刻暂停deployment [rootmaster ~]# kubectl set image deploy pc-deployment nginxnginx:1.20 -n test kubectl rollout pause deployment pc-deployment -n test deployment.apps/pc-deployment image updated deployment.apps/pc-deployment paused #观察更新状态 [rootmaster ~]# kubectl rollout status deploy pc-deployment -n test Waiting for deployment pc-deployment rollout to finish: 2 out of 4 new replicas have been updated... # 监控更新的过程可以看到已经新增了一个资源但是并未按照预期的状态去删除一个旧的资源就是因为使用了pause暂停命令 [rootmaster ~]# kubectl get rs -n test -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-5d89bdfbf9 3 3 3 19m nginx nginx:1.18 pc-deployment-675d469f8b 0 0 0 14m nginx nginx:1.19.2 pc-deployment-6c9f56fcfb 2 2 2 3m16s nginx nginx:1.20.4 [rootmaster ~]# kubectl get pods -n test NAME READY STATUS RESTARTS AGE pc-deployment-5d89bdfbf9-rj8sq 1/1 Running 0 7m33s pc-deployment-5d89bdfbf9-ttwgg 1/1 Running 0 7m35s pc-deployment-5d89bdfbf9-v4wvc 1/1 Running 0 7m34s pc-deployment-6c9f56fcfb-996rt 1/1 Running 0 3m31s pc-deployment-6c9f56fcfb-j2gtj 1/1 Running 0 3m31s # 确保更新的pod没问题了继续更新 [rootmaster ~]# kubectl rollout resume deploy pc-deployment -n test deployment.apps/pc-deployment resumed # 查看最后的更新情况 [rootmaster ~]# kubectl get rs -n test -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-5d89bdfbf9 0 0 0 21m nginx nginx:1.17.1 pc-deployment-675d469f8b 0 0 0 16m nginx nginx:1.17.2 pc-deployment-6c9f56fcfb 4 4 4 5m11s nginx nginx:1.17.4 [rootmaster ~]# kubectl get pods -n test NAME READY STATUS RESTARTS AGE pc-deployment-6c9f56fcfb-7bfwh 1/1 Running 0 37s pc-deployment-6c9f56fcfb-996rt 1/1 Running 0 5m27s pc-deployment-6c9f56fcfb-j2gtj 1/1 Running 0 5m27s pc-deployment-6c9f56fcfb-rf84v 1/1 Running 0 37s删除Deployment# 删除deployment其下的rs和pod也将被删除 [rootmaster ~]# kubectl delete -f pc-deployment.yaml deployment.apps pc-deployment deleted
k8s工作负载-Deployment的参数与灰度发布
发布时间：2026/6/12 15:00:35
一、Deployment的参数pc-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: test spec: replicas: 4 #保存历史版本数量 revisionHistoryLimit: 2 #控制滚动更新的速度(秒) minReadySeconds: 0 #标识Deployment只做数量维持、不做新的发布默认值false代表当前deploy可以更新) paused: false strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 0 type: RollingUpdate selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.18revisionHistoryLimitDeployment保留一部分更新历史中旧版本的 ReplicaSet 对象当我们执行回滚操作的时候就直接使用旧版本的ReplicaSet在 Deployment 资源保存历史版本数量有 spec.revisionHistoryLimit 属性进行定义。minReadySecondsDeployment支持使用 spec.minReadySeconds 字段来控制滚动更新的速度默认值为0表示新建的Pod对象-旦“就绪”将立即被视作可用随后即可开始下一轮更新过程如果设定了 spec.minReadySeconds: 3表示新建的Pod对象至少要成功运行多久才会被视作可用即就绪之后还要等待指定的 3s 才能开始下一批次的更新。在一个批次内新建的所有POD就绪后在转为可用状态前更新操作会被阻塞并且任何一个Pod就绪探测失败都会导致滚动更新被终止。因此为minReadySeconds设定一个合理的值不仅能够减缓更新的速度还能够让Deployment提前发现一部分程序因为Bug导致的升级故障。pausedpaused暂停部署默认是false标识Deployment只做数量维持、不做新的发布progressDeadlineSeconds滚动更新故障超时时长默认为600秒k8s 在升级过程中有可能由于各种原因升级卡住(这个时候还没有明确的升级失败)比如在拉取镜像权限不够等错误。如果配置 progressDeadlineSeconds当达到了时间如果还卡着则会上报这个异常情况这个时候这个 Deployment 状态就被标记为 False并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的升级操作。二、Deployment中的灰度发布金丝雀发布)是什么金丝雀发布又名灰度发布)是指在新与旧之间能够精确控制发布流程的一种发布方式在其上可以进行A/B testing即让一部分用户继续用旧产品特性A一部分用户开始用新产品特性B待充分测试验证新产品特性B以后再继续推进发布新版本的pod运行一段时间后如果没有报错那么就可以逐步扩大新版本的pod的数量并逐步完成更新如果新版本的pod运行一段时间后有报错那么就可以快速回退新版本的pod降级为发布之前的老版本A及时止损。K8s中的灰度发布Deployment控制器支持控制更新过程中的控制如“暂停(pause)”或“继续(resume)”更新操作。比如有一批新的Pod资源创建完成后立即暂停更新过程此时仅存在一部分新版本的应用主体部分还是旧的版本。然后再筛选一小部分的用户请求路由到新版本的Pod应用继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新否则立即回滚更新操作。这就是所谓的金丝雀发布。pc-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: pc-deployment namespace: test spec: replicas: 4 #滚动更新 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 0 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.18让deployment升级并立刻暂停# 更新deployment的版本第一轮迭代升级之后并立刻暂停deployment [rootmaster ~]# kubectl set image deploy pc-deployment nginxnginx:1.20 -n test kubectl rollout pause deployment pc-deployment -n test deployment.apps/pc-deployment image updated deployment.apps/pc-deployment paused #观察更新状态 [rootmaster ~]# kubectl rollout status deploy pc-deployment -n test Waiting for deployment pc-deployment rollout to finish: 2 out of 4 new replicas have been updated... # 监控更新的过程可以看到已经新增了一个资源但是并未按照预期的状态去删除一个旧的资源就是因为使用了pause暂停命令 [rootmaster ~]# kubectl get rs -n test -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-5d89bdfbf9 3 3 3 19m nginx nginx:1.18 pc-deployment-675d469f8b 0 0 0 14m nginx nginx:1.19.2 pc-deployment-6c9f56fcfb 2 2 2 3m16s nginx nginx:1.20.4 [rootmaster ~]# kubectl get pods -n test NAME READY STATUS RESTARTS AGE pc-deployment-5d89bdfbf9-rj8sq 1/1 Running 0 7m33s pc-deployment-5d89bdfbf9-ttwgg 1/1 Running 0 7m35s pc-deployment-5d89bdfbf9-v4wvc 1/1 Running 0 7m34s pc-deployment-6c9f56fcfb-996rt 1/1 Running 0 3m31s pc-deployment-6c9f56fcfb-j2gtj 1/1 Running 0 3m31s # 确保更新的pod没问题了继续更新 [rootmaster ~]# kubectl rollout resume deploy pc-deployment -n test deployment.apps/pc-deployment resumed # 查看最后的更新情况 [rootmaster ~]# kubectl get rs -n test -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-5d89bdfbf9 0 0 0 21m nginx nginx:1.17.1 pc-deployment-675d469f8b 0 0 0 16m nginx nginx:1.17.2 pc-deployment-6c9f56fcfb 4 4 4 5m11s nginx nginx:1.17.4 [rootmaster ~]# kubectl get pods -n test NAME READY STATUS RESTARTS AGE pc-deployment-6c9f56fcfb-7bfwh 1/1 Running 0 37s pc-deployment-6c9f56fcfb-996rt 1/1 Running 0 5m27s pc-deployment-6c9f56fcfb-j2gtj 1/1 Running 0 5m27s pc-deployment-6c9f56fcfb-rf84v 1/1 Running 0 37s删除Deployment# 删除deployment其下的rs和pod也将被删除 [rootmaster ~]# kubectl delete -f pc-deployment.yaml deployment.apps pc-deployment deleted
的演进与通信机制)
