Kubernetes常见部署方案--滚动更新、重新创建、蓝绿、金丝雀
常見的部署方案:
滾動更新:服務不會停止,但是整個pod會有新舊并存的情況。
重新創建:先停止舊的pod,然后再創建新的pod,這個過程服務是會間斷的。
藍綠部署:無需停機,風險較小。部署v1的應用(一開始的狀態)所有外部請求的流量都打到這個版本上。部署版本2的應用版本2的代碼與版本1不同(新功能、Bug修復等)。將流量從版本1切換到版本2。如版本2測試正常,就刪除版本1正在使用的資源(例如實例),從此正式用版本2。
金絲雀部署:金絲雀發布一般先發 1 臺,或者一個小比例,例如 2% 的服務器,主要做流量驗證用,也稱為金絲雀 (Canary) 測試(國內常稱灰度測試)。以前曠工開礦下礦洞前,先會放一只金絲雀進去探是否有有毒氣體,看金絲雀能否活下來,金絲雀發布由此得名。簡單的金絲雀測試一般通過手工測試驗證,復雜的金絲雀測試 需要比較完善的監控基礎設施配合,通過監控指標反饋,觀察金絲雀的健康狀況,作為后續發布或回退的依據。如果金絲測試通過,則把剩余的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗,則直接回退金絲雀,發布失敗。
滾動更新:
創建rollingupdate.yaml 文件:
maxUnavailable:最大無效pod數。
maxSurge:最大激增pod數。
apiVersion: apps/v1
kind: Deployment
metadata:
name: rollingupdate
spec:
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
selector:
matchLabels:
app: rollingupdate
replicas: 4
template:
metadata:
labels:
app: rollingupdate
spec:
containers:
- name: rollingupdate
image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: rollingupdate
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: rollingupdate
type: ClusterIP
kubectl apply -f rollingupdate.yaml
kubectl get pods
kubectl get svc
curl svc r-ip/dockerfile
修改rollingupdate.yaml文件,將鏡像修改成v2.0
# 在w1上,不斷地訪問觀察輸出 while sleep 0.2;do curl cluster-ip/dockerfile;echo "";done # 在w2上,監控pod kubectl get pods -w # 使得更改生效 kubectl apply -f rollingupdate.yaml kubectl get pods
發現新舊pod是會共存的,并且可以訪問測試看一下
重新創建:
創建recreate.yaml 文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: recreate
spec:
strategy:
type: Recreate
selector:
matchLabels:
app: recreate
replicas: 4
template:
metadata:
labels:
app: recreate
spec:
containers:
- name: recreate
image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
ports:
- containerPort: 8080
livenessProbe:
tcpSocket:
port: 8080
kubectl apply -f recreate.yaml
kubectl get pods
修改recreate.yaml文件 改成 v2.0,執行kubectl apply -f recreate.yaml使其生效。同時在w2上進行觀察kubectl get pods -w 。發現pod是先停止,然后再創建新的
Have a try
kubectl rollout pause deploy/deploy-name #暫停資源 kubectl rollout resume deploy/rollingupdate #回復暫停資源 kubectl rollout undo deploy/rollingupdate --to-revision=2 # 回到上一個版本
藍綠部署:
創建bluegreen.yaml :
#deploy
apiVersion: apps/v1
kind: Deployment
metadata:
name: blue
spec:
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
selector:
matchLabels:
app: bluegreen
replicas: 4
template:
metadata:
labels:
app: bluegreen
version: v1.0
spec:
containers:
- name: bluegreen
image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
ports:
- containerPort: 8080
kubectl apply -f bluegreen.yaml
kubectl get pods
創建bluegreen-service.yaml :
apiVersion: v1
kind: Service
metadata:
name: bluegreen
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: bluegreen
version: v1.0
type: ClusterIP
kubectl apply -f bluegreen-service.yaml
kubectl get svc
在w1上不斷訪問觀察while sleep 0.3;do curl cluster-ip/dockerfile;echo "";done
修改bluegreen.yaml
01-deployment-name:blue ---> green 02-image:v1.0---> v2.0 03-version:v1.0 ---> v2.0
kubectl apply -f bluegreen.yaml
kubectl get pods
同時觀察剛才訪問的地址有沒有變化,可以發現,兩個版本就共存了,并且之前訪問的地址沒有變化
修改bluegreen-service.yaml :
# 也就是把流量切到2.0的版本中 selector: app: bluegreen version: v2.0
kubectl apply -f bluegreen-service.yaml
kubectl get svc
同時觀察剛才訪問的地址有沒有變化。發現流量已經完全切到了v2.0的版本上
金絲雀部署/灰度發布/AB測試:
修改上述 bluegreen-service.yaml
selector: app: bluegreen version: v2.0 # 把version刪除掉,只是根據bluegreen進行選擇
kubectl apply -f bluegreen-service.yaml
同時觀察剛才訪問的地址有沒有變化,此時新舊版本能夠同時被訪問到,AB測試,新功能部署少一些的實例.
來源:https://www.cnblogs.com/wuzhenzhao/p/12165588.html
總結
以上是生活随笔為你收集整理的Kubernetes常见部署方案--滚动更新、重新创建、蓝绿、金丝雀的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: n个一位数字的数组中选取任意数目的数字,
- 下一篇: 一个数变成0的概率有多少?(记忆化搜索)