免费数据源网站加速游戏流畅的软件
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-demo2.失败我们就回滚
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=1to-revision 指定回滚的版本
6.可以将我们的滚动暂停
kubectl rollout pause deployment/deployment-demoresume 恢复滚动
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-containerkubectl 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 只会选择最终的版本进行部署，忽略中间的版本的执行！
