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-demo
 name: deployment-demo
spec:
 replicas: 5
 selector:
  matchLabels:
   app: deployment-demo
 template:
  metadata:
   labels:
    app: deployment-demo
  spec:
   containers:
     - image: wangyanglinux/myapp:v1.0
       name: 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-demo
 name: deployment-demo
spec:
 revisionHistoryLimit: 0
 replicas: 5
 selector:
  matchLabels:
   app: deployment-demo
 template:
  metadata:
   labels:
    app: deployment-demo
  spec:
   containers:
     - image: wangyanglinux/myapp:v3.0
       name: deployment-demo-container

设为0 就好了

spec:

 revisionHistoryLimit: 0

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

kubectl delete deployment --all

只剩一个了

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

4.多个rollout并行的状态

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

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

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

 

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值