当前位置：首页 > wzjs >正文

浙江响应式网站建设制作优化教程网官网

wzjs 2025/8/2 5:35:58

浙江响应式网站建设制作,优化教程网官网,挂网站需要什么服务器,龙岩做网站设计公司1.概述用极小的版本数量去测试当前代码的稳定性进行部署动作就叫做金丝雀部署 2.如何使用 1.第一条命令 patch 打补丁给deployment 控制器打哪个控制器呢名称为 deployment-demo的控制器 -p 指定我们的补丁选项配置为滚动更新的允许多一个但不能少这就相当…

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

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