Deployment控制器支持自定义控制更新过程中的滚动节奏,如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,在筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。
kubectl create deployment nginx-test --image=nginx:1.14 --replicas=3
kubectl get pods,deploy -o wide
kubectl expose deploy nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
kubectl get svc -o wide
curl -I 192.168.109.11:31811
kubectl describe deployment nginx-test | grep Image
在不定义CHANGE-CAUSE的情况下,缺省值为,当历史版本较多时,不便于咱们回滚时辨认版本号。因此,建议定义CHANGE-CAUSE为服务版本以帮助咱们辨认当前服务。
kubectl rollout history deploy/nginx-test
一般通过修改配置的方式定义change-cause
[root@master ~]# kubectl edit deploy/nginx-test
......
kind: Deployment
metadata:
annotations:
#下行可定义历史版本revision
deployment.kubernetes.io/revision: "1"
#在Deployment的matadata项下的annotations中如下行定义change-cause
kubernetes.io/change-cause: "nginx1.14"
......
kubectl rollout history deploy/nginx-test
kubectl set image deploy/nginx-test nginx=nginx:1.15 && kubectl rollout pause deploy/nginx-test
kubectl rollout status deploy/nginx-test
可以看到已经新增了一个pod,但是并未按照预期的状态去删除一个旧的资源,就是因为使用了pause暂停命令
kubectl get pods -w
kubectl get pod -o wide
kubectl rollout history deploy/nginx-test
[root@master ~]# kubectl edit deploy/nginx-test
kind: Deployment
metadata:
annotations:
#下行的revison自动更新为2
deployment.kubernetes.io/revision: "2"
#修改下行的change-cause为nginx1.15
kubernetes.io/change-cause: nginx1.15
测试新版本没问题继续更新
kubectl rollout resume deploy/nginx-test
kubectl get pods -w