Kubernetes - Pod控制器 - Deployment - 金丝雀部署

1.概述

用极小的版本数量 去测试当前代码的稳定性 进行部署动作 就叫做金丝雀部署

2.如何使用 

 1.第一条命令

patch 打补丁 给deployment 控制器打

哪个控制器呢 名称 为 deployment-demo的控制器

-p 指定我们的补丁选项

配置为 滚动更新的 允许多一个 但不能少 

这就相当于修改了我们滚动的机制

kubectl patch deployment deployment-demo -p \
'{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'

2.第二条命令 

开启滚动更新 然后直接暂停滚动更新 达到 多出那一个新版本 的 pod 

这就是金丝雀部署的关键

kubectl patch deployment deployment-demo --patch \
'{"spec":{"template":{"spec":{"containers":[{"name":"deployment-demo-container","image":"wangyanglinux/myapp:v2.0"}]}}}}' && kubectl rollout pause deploy deployment-demo

第一部分可以 setimage 也可以

1.没有问题 我们将执行 继续滚动更新

kubectl rollout resume deploy deployment-demo

2.失败我们就回滚

kubectl rollout undo  deployment/deployment名

kubectl rollout undo  deployment/deployment-demo

这个永远会回到它的上一个版本 

也就是 v1 -> v2 ->v3 

v3 执行 undo 回到 v2  如果再次执行 它会回到 v3 而不是 v1

3.若想回到v1

kubectl rollout undo deployment/deployment-demo && kubectl rollout status deployments deployment-demo

 可以实时监测回滚状态

如果回滚成功 rollout status 的返回码 为 0

kubectl rollout undo deployment/deployment-demo && kubectl rollout status deployments deployment-demo 

echo $?

 4.查看回滚历史

kubectl rollout history deployment/deployment-demo

 为什么是 none呢？

原因是 ：前面 执行 kubectl create -f deployment.yaml 后面跟了一个参数 --record

kubectl create -f 3.deployment.yaml  --record

更新镜像

kubectl set image deployment deployment-demo deployment-demo-container=wangyanglinux/myapp:v2.0 --record

再执行

 kubectl rollout history deployment/deployment-demo

1.会出现一个情况 

如果你有一天忘记加 --record 他会把上一次 的滚动的命令记录抄下来 加到最新的版本里面  

5.回滚到指定的版本

kubectl rollout undo deployment/deployment-demo --to-revision=1

to-revision 指定回滚的版本

 6.可以将我们的滚动暂停

kubectl rollout pause deployment/deployment-demo

resume 恢复滚动

3.rollout 命令

1.清理策略

举个例子：

比如nginx服务器 ，在它的配置目录下 ,我们会看到一个叫 nginx.conf 

/usr/local/nginx/conf/nginx.conf

默认主配置文件 ,但是每一次我要做修改的时候,一般不会对它直接做修改,防止万一你改坏了还回不去怎么办,所以每个公司的要求可能不太一样,但基本上都有这么一个相类似的感念,比如如果是我之前的公司,我们会要求你先去做一个动作copy  将当前的配置文件改成  比如 nginx.conf 年-月-日-时-分 那这个信息有了之后，在-当前姓名， -你对当前改变做一个简单的描述 

nginx.conf 年-月-日-时-分-姓名-比如把我们当前端口升级到我们对应的8080.conf命名完成后，我再去对当前的这么一个配置文件进行改变,万一我们改坏了 我们还可以利用这个配置文件进行改回去 我们想更新 想滚动更新是不是也可以借助这样一个思想

2.模拟一下

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: deployment-demoname: deployment-demo
spec:replicas: 5selector:matchLabels:app: deployment-demotemplate:metadata:labels:app: deployment-demospec:containers:- image: wangyanglinux/myapp:v1.0name: deployment-demo-container

kubectl apply -f deployment.yaml

 cp -a deployment.yaml deployment-2025-03-21-18-45-jmj-updateV2.0.yaml

 kubectl apply -f deployment-2025-03-21-18-45-jmj-updateV2.0.yaml && kubectl get pod

查看一个文件大小

du -sh deployment.yaml

还有人说，我们当前用来资源清单回滚 但是

这些还是存在我们的etcd中

 3.设置清理策略

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: deployment-demoname: deployment-demo
spec:revisionHistoryLimit: 0replicas: 5selector:matchLabels:app: deployment-demotemplate:metadata:labels:app: deployment-demospec:containers:- image: wangyanglinux/myapp:v3.0name: deployment-demo-container

设为0 就好了

spec:

 revisionHistoryLimit: 0

改完以后我们重新去部署创建一下

kubectl delete deployment --all

只剩一个了

 老的rs 没有了 ，没有历史记录保存在 etcd了 我们就使用文件来进行回滚

4.多个rollout并行的状态

它会直接到达最终态，也就是最后一次应用的版本的状态 不会依次执行，因为没有意义

它是容器的创建杀死，而不是升级，所以直接启动最终态的容器就完事了

多个 kubectl rollout 并行执行，那么 Kubernetes 只会选择最终的版本进行部署，忽略中间的版本的执行！