建站
咨詢
售后
建站咨詢
新聞中心
Kruise Rollouts 是 OpenKruise 提供的一個(gè)旁路組件，用于提供漸進(jìn)式交付功能。它支持金絲雀、多批次和 A/B 測(cè)試交付模式，可以幫助實(shí)現(xiàn)對(duì)應(yīng)用程序變更的平穩(wěn)和可控發(fā)布，同時(shí)它與 Gateway API 和各種 Ingress 實(shí)現(xiàn)的兼容性使其更容易與你現(xiàn)有基礎(chǔ)架構(gòu)集成。總的來(lái)說(shuō)，Kruise Rollouts 對(duì)于希望優(yōu)化其部署流程的 Kubernetes 用戶來(lái)說(shuō)是一個(gè)有價(jià)值的工具！
成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括內(nèi)黃網(wǎng)站建設(shè)、內(nèi)黃網(wǎng)站制作、內(nèi)黃網(wǎng)頁(yè)制作以及內(nèi)黃網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，內(nèi)黃網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到內(nèi)黃省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
Kruise Rollouts
Kruise Rollouts 具有以下幾個(gè)主要特點(diǎn)：
- 更多的發(fā)布策略
- Deployment、CloneSet、StatefulSet 和 Advanced StatefulSet 的多批次更新策略。
- Deployment 的金絲雀更新策略。
- 更多流量路由管理策略
-
在更新工作負(fù)載時(shí)進(jìn)行流量細(xì)粒度加權(quán)流量轉(zhuǎn)移。
-
基于 HTTP 頭和 Cookie 進(jìn)行 A/B 測(cè)試，根據(jù)流量進(jìn)行轉(zhuǎn)移。
-
更多流量協(xié)議支持
-
Ingress 控制器集成：NGINX、ALB、Higress。
-
通過(guò) Gateway API 與服務(wù)網(wǎng)格集成。
-
可插拔的 Lua 腳本，輕松擴(kuò)展到其他 Kubernetes 流量協(xié)議（甚至 CRD）。
-
容易集成
-
輕松與 GitOps 風(fēng)格的基于 Kubernetes 的 PaaS 集成。
和其他發(fā)布組件相比，Kruise Rollouts 有什么優(yōu)勢(shì)？
|
組件 |
Kruise Rollouts |
Argo Rollouts |
Flux Flagger |
|
核心概念 |
增強(qiáng)現(xiàn)有工作負(fù)載 |
替換你的工作負(fù)載 |
管理你的工作負(fù)載 |
|
架構(gòu) |
旁路 |
一種新的工作負(fù)載類型 |
旁路 |
|
插拔式組件，熱插拔 |
是 |
否 |
否 |
|
發(fā)布類型 |
多批次，金絲雀，A/B 測(cè)試 |
多批次，金絲雀，藍(lán)綠部署，A/B 測(cè)試 |
金絲雀，藍(lán)綠部署，A/B 測(cè)試 |
|
工作負(fù)載類型 |
Deployment,StatefulSet,CloneSet,Advaned StatefulSet,DaemonSet(WIP) |
Agro-Rollout |
Deployment. DaemonSet |
|
流量類型 |
Ingress、GatewayAPI、CRD（需要 Lua 腳本） |
Ingress、GatewayAPI、APISIX、Traefik、SMI 等 |
Ingress、GatewayAPI、APISIX、Traefik、SMI 等 |
|
遷移成本 |
無(wú)需遷移你的工作負(fù)載和 Pod |
必須遷移你的工作負(fù)載和 Pod |
必須遷移你的 Pod |
|
HPA 兼容 |
是 |
是 |
否 |
整體上對(duì)比，Kruise Rollouts 與 Argo Rollouts 有相似的架構(gòu)，但是功能上 Kruise Rollouts 更加強(qiáng)大，支持更多的發(fā)布策略和流量路由管理策略，同時(shí)也支持更多的流量協(xié)議。Kruise Rollouts 也是一個(gè)旁路組件，不需要遷移你的工作負(fù)載和 Pod，你可以在任何時(shí)候安裝它，它會(huì)自動(dòng)發(fā)現(xiàn)你的工作負(fù)載并管理它們。而和 Flagger 相比，Kruise Rollouts 支持更多的發(fā)布策略和流量路由管理策略，同時(shí)也支持更多的流量協(xié)議。
所以，如果你想要更多的發(fā)布策略和流量路由管理策略，同時(shí)也想要更多的流量協(xié)議支持，那么 Kruise Rollouts 就是一個(gè)不錯(cuò)的選擇！
安裝
要使用 Kruise Rollouts，需要 Kubernetes 版本 >= 1.19，如果要使用 CloneSet 作為工作負(fù)載類型，則還需要安裝 OpenKruise。
這里我們使用 Helm 來(lái)安裝 Kruise Rollouts，你可以使用 helm repo add 命令來(lái)添加 Kruise 的 Helm 倉(cāng)庫(kù)：
helm repo add openkruise https://openkruise.github.io/charts/
helm repo update
然后可以使用 helm install 命令來(lái)一鍵安裝 Kruise Rollouts：
helm upgrade --install kruise-rollout openkruise/kruise-rollout --version 0.3.0
如果你沒(méi)辦法訪問(wèn) DockerHub，可以使用阿里云的鏡像倉(cāng)庫(kù)：
helm upgrade --install kruise-rollout openkruise/kruise-rollout --version 0.3.0 --set image.repository=openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/kruise-rollout
該命令默認(rèn)會(huì)在 kruise-rollout 命名空間中安裝 Kruise Rollouts，可以通過(guò) kubectl get pods -n kruise-rollout 命令來(lái)查看安裝結(jié)果：
kubectl get pods -n kruise-rollout
NAME READY STATUS RESTARTS AGE
kruise-rollout-controller-manager-b4d64789d-9kmgm 1/1 Running 0 3m18s
kruise-rollout-controller-manager-b4d64789d-gln5n 1/1 Running 0 3m18s
如果想更改默認(rèn)安裝的命名空間，則可以通過(guò) installation.namespace 參數(shù)來(lái)進(jìn)行指定。
安裝后可以看到在 kruise-rollout 命名空間中多了一個(gè) kruise-rollout-controller-manager 的 Deployment，它是 Kruise Rollouts 的控制器，它會(huì)自動(dòng)發(fā)現(xiàn)你的工作負(fù)載并管理它們。
同樣還會(huì)安裝 3 個(gè)用于 Rollout 的 CRD：
kubectl get crd |grep rollout
batchreleases.rollouts.kruise.io 2023-04-08T06:44:51Z
rollouthistories.rollouts.kruise.io 2023-04-08T06:44:51Z
rollouts.rollouts.kruise.io 2023-04-08T06:44:51Z
使用
接下來(lái)我們來(lái)使用 Kruise Rollouts 來(lái)管理一個(gè)工作負(fù)載，這里我們使用 Deployment 作為示例。
首先我們創(chuàng)建一個(gè)如下所示的 Deployment 工作負(fù)載：
# workload-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: workload-demo
namespace: default
spec:
replicas: 10
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: busybox
image: busybox:1.28.3
command: ["/bin/sh", "-c", "sleep 100d"]
env:
- name: VERSION
value: "version-1"
直接應(yīng)用該資源對(duì)象即可：
kubectl apply -f workload-demo.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
workload-demo-6c7764b765-69ls9 1/1 Running 0 25m
workload-demo-6c7764b765-9zxr7 1/1 Running 0 26m
workload-demo-6c7764b765-hrd55 1/1 Running 0 25m
workload-demo-6c7764b765-krhfd 1/1 Running 0 25m
workload-demo-6c7764b765-mvrdk 1/1 Running 0 25m
workload-demo-6c7764b765-qzzl2 1/1 Running 0 25m
workload-demo-6c7764b765-tgt4k 1/1 Running 0 26m
workload-demo-6c7764b765-tjgcg 1/1 Running 0 26m
workload-demo-6c7764b765-x5b94 1/1 Running 0 26m
workload-demo-6c7764b765-xj5hb 1/1 Running 0 26m
多批次更新策略
多批次更新策略是 Kruise Rollouts 的一個(gè)特性，它可以讓你在更新工作負(fù)載時(shí)，可以控制每批次更新的 Pod 數(shù)量，以及每批次更新的時(shí)間間隔。
接下來(lái)我們需要?jiǎng)?chuàng)建一個(gè) Rollout 對(duì)象來(lái)管理這個(gè)工作負(fù)載，比如我們想使用多批次更新策略將 Deployment 從 version-1? 升級(jí)到 version-2。
- 第 1 批：只升級(jí) 1 個(gè) Pod。
- 在第 2 批中：50% 的 Pod 應(yīng)該升級(jí)，即 5 個(gè)更新的 Pod。
- 在第 3 批中：100% 的 Pod 應(yīng)該被升級(jí)，即 10 個(gè)更新的 Pod。
多批次更新策略
目前，多批次更新策略可以在 CloneSet、StatefulSet、Advanced StatefulSet 和 Deployment 上工作。
那么我們可以創(chuàng)建如下所示的 Rollout 對(duì)象：
# rollouts-demo.yaml
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
name: rollouts-demo
namespace: default
annotations:
rollouts.kruise.io/rolling-style: partition # 使用多批次更新策略，只能配置 "partition" or "canary"
# "partition" 意味著像 CloneSet 一樣分批滾動(dòng)，不會(huì)創(chuàng)建任何額外的 Workload
# “canary” 表示以金絲雀方式滾動(dòng)，并將創(chuàng)建一個(gè)金絲雀工作負(fù)載，對(duì)于Deployment默認(rèn)是canary
spec:
objectRef: # 定義工作負(fù)載
workloadRef: # 關(guān)聯(lián)需要管理的工作負(fù)載
apiVersion: apps/v1
kind: Deployment
name: workload-demo
strategy: # 定義升級(jí)策略
canary: # 使用 Canary 策略
steps: # 定義多批次更新策略
- replicas: 1
- replicas: 50%
- replicas: 100%
直接創(chuàng)建該 Rollout 對(duì)象即可。
kubectl apply -f rollouts-demo.yaml
kubectl get rollout
NAME STATUS CANARY_STEP CANARY_STATE MESSAGE AGE
rollouts-demo Healthy 3 Completed workload deployment is completed 6s
創(chuàng)建 Rollout 對(duì)象后，其實(shí)已經(jīng)開(kāi)始管理工作負(fù)載了，上面的 kubectl get rollout 命令可以看到 Rollout 的狀態(tài)為 Healthy，但現(xiàn)在工作負(fù)載的版本還是 version-1，我們可以通過(guò)將 Deployment 升級(jí)到 version-2 版本，來(lái)觀察下 Rollout 的狀態(tài)變化。
kubectl patch deployment workload-demo -p \
'{"spec":{"template":{"spec":{"containers":[{"name":"busybox", "env":[{"name":"VERSION", "value":"version-2"}]}]}}}}'
稍等片刻，我們會(huì)看到 Deployment 更新了一個(gè) Pod：
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
workload-demo 10/10 1 10 30m
kubectl get replicaset
NAME DESIRED CURRENT READY AGE
workload-demo-6c7764b765 9 9 9 30m
workload-demo-6dd59d49b5 1 1 1 34s
kubectl get pods
NAME READY STATUS RESTARTS AGE
workload-demo-6c7764b765-69ls9 1/1 Running 0 30m
workload-demo-6c7764b765-hrd55 1/1 Running 0 30m
workload-demo-6c7764b765-krhfd 1/1 Running 0 30m
workload-demo-6c7764b765-mvrdk 1/1 Running 0 30m
workload-demo-6c7764b765-qzzl2 1/1 Running 0 30m
workload-demo-6c7764b765-tgt4k 1/1 Running 0 31m
workload-demo-6c7764b765-tjgcg 1/1 Running 0 31m
workload-demo-6c7764b765-x5b94 1/1 Running 0 31m
workload-demo-6c7764b765-xj5hb 1/1 Running 0 31m
workload-demo-6dd59d49b5-mpthm 1/1 Running 0 52s
現(xiàn)在我們?cè)俨榭?Rollout 的狀態(tài)：
kubectl describe rollout rollouts-demo
Name: rollouts-demo
Namespace: default
Labels:
Annotations: rollouts.kruise.io/hash: 77cxd69w47b7bwddwv2w7vxvb4xxdbwcx9x289vw69w788w4w6z4x8dd4vbz2zbw
rollouts.kruise.io/rolling-style: partition
API Version: rollouts.kruise.io/v1alpha1
Kind: Rollout
# ......
Status:
Canary Status:
Canary Ready Replicas: 1
Canary Replicas: 1
Canary Revision: 6dd59d49b5
Current Step Index: 1
Current Step State: StepPaused
Last Update Time: 2023-04-08T07:27:24Z
Message: BatchRelease is at state Ready, rollout-id , step 1
Observed Workload Generation: 8
Pod Template Hash: 6dd59d49b5
Rollout Hash: 77cxd69w47b7bwddwv2w7vxvb4xxdbwcx9x289vw69w788w4w6z4x8dd4vbz2zbw
Stable Revision: 6c7764b765
Conditions:
Last Transition Time: 2023-04-08T07:27:16Z
Last Update Time: 2023-04-08T07:27:16Z
Message: Rollout is in Progressing
Reason: InRolling
Status: True
Type: Progressing
Message: Rollout is in step(1/3), and you need manually confirm to enter the next step
Observed Generation: 2
Phase: Progressing
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Progressing 110s rollout-controller upgrade step(1) canary pods with new versions done
kubectl get rollout
NAME STATUS CANARY_STEP CANARY_STATE MESSAGE AGE
rollouts-demo Progressing 1 StepPaused Rollout is in step(1/3), and you need manually confirm to enter the next step 6m17s
可以看到現(xiàn)在 Rollout 的狀態(tài)為 Progressing，并且在第 1 步，當(dāng)前的金絲雀狀態(tài)為 StepPaused，這是因?yàn)槲覀兪褂昧?nbsp;partition 策略，需要手動(dòng)確認(rèn)才能進(jìn)入下一步。
為了方便手動(dòng)確認(rèn)，我們可以安裝使用 kubectl-kruise 這個(gè)插件。如果你已經(jīng)安裝過(guò) Krew 這個(gè)插件，那么可以直接通過(guò) kubectl krew install kruise-tools 來(lái)安裝。
如果沒(méi)有安裝 Krew，可以直接前往 Release 頁(yè)面 下載對(duì)應(yīng)的二進(jìn)制文件，然后將其放到 PATH 路徑下即可。
tar -xvf kubectl-kruise-darwin-arm64.tar.gz
sudo mv darwin-arm64/kubectl-kruise /usr/local/bin/
然后就可以使用 kubectl-kruise 或者 kubectl kruise 命令了：
kubectl-kruise --help
# or
kubectl kruise --help
kubectl-kruise 插件安裝完成后，我們就可以通過(guò) kubectl-kruise rollout approve 命令來(lái)手動(dòng)確認(rèn)繼續(xù)發(fā)布第二批次了：
kubectl kruise rollout approve rollout/rollouts-demo -n default
rollout.rollouts.kruise.io/rollouts-demo approved
確認(rèn)后現(xiàn)在我們?cè)偃ゲ榭聪卢F(xiàn)在工作負(fù)載的狀態(tài)：
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
workload-demo 10/10 5 10 45m
kubectl get replicaset
NAME DESIRED CURRENT READY AGE
workload-demo-6c7764b765 5 5 5 45m
workload-demo-6dd59d49b5 5 5 5 15m
kubectl get rollout
NAME STATUS CANARY_STEP CANARY_STATE MESSAGE AGE
rollouts-demo Progressing 2 StepPaused Rollout is in step(2/3), and you need manually confirm to enter the next step 18m
可以看到現(xiàn)在工作負(fù)載已經(jīng)有 5 個(gè)是新版本的了，Rollout 對(duì)象也已經(jīng)進(jìn)入了第 2 步，如果我們?cè)俅问謩?dòng)確認(rèn)，那么就會(huì)進(jìn)入第 3 步，然后就會(huì)將所有的工作負(fù)載全部更新為新版本。
繼續(xù)執(zhí)行確認(rèn)操作：
kubectl kruise rollout approve rollout/rollouts-demo -n default
rollout.rollouts.kruise.io/rollouts-demo approved
可以看到現(xiàn)在工作負(fù)載已經(jīng)全部更新為新版本了，Rollout 對(duì)象也顯示金絲雀發(fā)布已經(jīng)完成：
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
workload-demo 10/10 10 10 47m
kubectl get replicaset
NAME DESIRED CURRENT READY AGE
workload-demo-6c7764b765 0 0 0 48m
workload-demo-6dd59d49b5 10 10 10 17m
kubectl get rollout
NAME STATUS CANARY_STEP CANARY_STATE MESSAGE AGE
rollouts-demo Healthy 3 Completed Rollout progressing has been completed 21m
到這里我們的分批次發(fā)布就完成了。
上面我們使用 kubectl kruise rollout approve 命令來(lái)進(jìn)行手動(dòng)確認(rèn)的，那么還有其他方法嗎？目前，有兩種方法，例如，如果你已完成第一批并要發(fā)送第二批：
- 方法一：可以將第一批的 pause.duration 字段設(shè)置為 duration:0，會(huì)自動(dòng)進(jìn)入下一批。
- 方法二：可以更新 rollout.status.canaryStatus.currentStepState 字段為 StepReady，同樣會(huì)自動(dòng)進(jìn)入下一批次。
這兩種方法都有自己的優(yōu)點(diǎn)和缺點(diǎn)：
- 對(duì)于第一種方法，它可以確保你的操作冪等性，但是在下一個(gè)發(fā)布之前，你需要將發(fā)布策略重置回其原始狀態(tài)（例如，將持續(xù) duration 重置為 nil）
kind: Rollout
spec:
strategy:
canary:
steps:
- replicas: 1
pause:
duration: 0
- ... ...
- 對(duì)于方法二，你無(wú)需在下一次發(fā)布之前更改任何內(nèi)容。不過(guò)在確認(rèn)之前，需要查看 Rollout 的狀態(tài)，使用 update 接口，而不是 Kubernetes 客戶端的 patch 接口，或者使用我們的 kubectl-kruise 工具，也就是上面我們使用的方法。
kubectl kruise rollout approve rollout/-n
那么如果現(xiàn)在我們想要回滾操作怎么辦呢？事實(shí)上，Kruise Rollout 不提供直接回滾的能力。Kruise Rollout 更喜歡用戶可以直接回滾工作負(fù)載規(guī)范來(lái)回滾他們的應(yīng)用程序。當(dāng)用戶需要從 version-2? 回滾到 version-1 時(shí)，Kruise Rollout 會(huì)使用原生的滾動(dòng)升級(jí)策略快速回滾，而不是遵循 multi-batch checkpoint 策略。
此外還有一些其他注意事項(xiàng)值得我們注意：
- 持續(xù)發(fā)布：假設(shè) Rollout 正在從 version-1 發(fā)布到 version-2（未完成）。現(xiàn)在，工作負(fù)載被修改為 version-3，Rollout 將從開(kāi)始步驟（第一步）開(kāi)始進(jìn)行。
- HPA 兼容性：假設(shè)你將 HPA 配置為你的工作負(fù)載并使用多批更新策略，我們建議使用百分比來(lái)指定 steps[x].replicas。如果在 rollout 過(guò)程中副本被放大/縮小，舊版本和新版本副本將根據(jù)百分比配置進(jìn)行縮放。
金絲雀發(fā)布策略
金絲雀發(fā)布策略允許用戶在發(fā)布新版本時(shí)，將流量分配給新版本的一小部分，以便在發(fā)布新版本之前，可以對(duì)其進(jìn)行測(cè)試。如果測(cè)試通過(guò)，則可以將流量分配給新版本的所有副本，否則可以回滾到舊版本。
目前金絲雀發(fā)布策略只支持 Deployment 工作負(fù)載。
金絲雀發(fā)布策略
比如現(xiàn)在我們有一個(gè)如下所示的 Deployment 工作負(fù)載：
# workload-canary-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: echoserver
labels:
app: echoserver
spec:
replicas: 5
selector:
matchLabels:
app: echoserver
template:
metadata:
labels:
app: echoserver
spec:
containers:
- name: echoserver
image: registry.aliyuncs.com/google_containers/echoserver:1.10
ports:
- containerPort: 8080
env:
- name: VERSION # 表示當(dāng)前是 v1 版本
value: v1
- name: NODE_NAME # 這里我們使用該環(huán)境變量來(lái)表示版本，這樣后續(xù)只需要更改該環(huán)境變量的值即可
value: version1
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
# nginx ingress 配置
---
apiVersion: v1
kind: Service
metadata:
name: echoserver
labels:
app: echoserver
spec:
ports:
- port: 80
targetPort: 8080
selector:
app: echoserver
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: echoserver
spec:
ingressClassName: nginx
rules:
- host: echo.k8s.local
http:
paths:
- path: /apis/echo
pathType: Exact
backend:
service:
name: echoserver
port:
number: 80
由于要我們這里要使用金絲雀發(fā)布策略，所以需要指定流量來(lái)源，這里我們使用 Ingress 來(lái)指定流量來(lái)源。在 Ingress 中，我們指定了 echo.k8s.local 作為域名，然后在 paths 中指定了 /apis/echo 作為路徑。
直接應(yīng)用上面的資源對(duì)象即可：
kubectl apply -f workload-canary-demo.yaml
kubectl get ingress echoserver
NAME CLASS HOSTS ADDRESS PORTS AGE
echoserver nginx echo.k8s.local 10.98.12.94 80 2m42s
kubectl get svc echoserver
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
echoserver ClusterIP 10.97.158.1480/TCP 2m48s
kubectl get pods -l app=echoserver
NAME READY STATUS RESTARTS AGE
echoserver-6995b4bc86-4dzvb 1/1 Running 0 2m54s
echoserver-6995b4bc86-9b4qg 1/1 Running 0 2m54s
echoserver-6995b4bc86-bl82m 1/1 Running 0 2m54s
echoserver-6995b4bc86-n27v7 1/1 Running 0 2m54s
echoserver-6995b4bc86-wgjwp 1/1 Running 0 2m54s
部署后我們就可以通過(guò) http://echo.k8s.local/apis/echo 來(lái)訪問(wèn)我們的服務(wù)了。
echo 服務(wù)
然后接下來(lái)我們就可以使用 Rollout 來(lái)進(jìn)行金絲雀發(fā)布了，定義一個(gè)如下所示的 Rollout 對(duì)象：
# rollout-canary-demo.yaml
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
name: rollouts-canary-demo
annotations:
rollouts.kruise.io/rolling-style: canary # 指定金絲雀發(fā)布策略
spec:
objectRef:
workloadRef:
apiVersion: apps/v1
kind: Deployment
name: echoserver
strategy:
canary: # 金絲雀發(fā)布策略
steps: # 步驟
- weight: 5 # 導(dǎo)入5%的流量
pause: {} # 表示人工確認(rèn)
replicas: 1 # 第一批發(fā)布的副本個(gè)數(shù)
- weight: 40 # 導(dǎo)入40%的流量，沒(méi)有配置 replicas，也表示發(fā)布40%的副本數(shù)
pause: { duration: 30 } # 不需要人工確認(rèn)，等待30s繼續(xù)下一批
- weight: 60
pause: { duration: 30 }
- weight: 80
pause: { duration: 30 }
- weight: 100
pause: { duration: 10 }
trafficRoutings: # 流量路由
- service: echoserver
ingress:
classType: nginx
name: echoserver
同樣直接應(yīng)用上面的資源對(duì)象即可：
kubectl apply -f rollout-canary-demo.yaml
rollout.kruise.io/rollouts-canary-demo created
kubectl get rollout rollouts-canary-demo
NAME STATUS CANARY_STEP CANARY_STATE MESSAGE AGE
rollouts-canary-demo Healthy 5 Completed workload deployment is completed 2m53s
目前第一次不會(huì)有任何變化，當(dāng)我們進(jìn)行下一次發(fā)布的時(shí)候才能看到效果，比如這里我們修改一下 workload-canary-demo.yaml 中的 NODE_NAME 環(huán)境變量，將其修改為 version2，然后再次應(yīng)用，這樣就會(huì)觸發(fā)一次新的發(fā)布。
我們可以開(kāi)一個(gè)新的終端來(lái)查看工作負(fù)載的版本變化：
while true; do curl -s http://echo.k8s.local/apis/echo |grep node; sleep 1; done
應(yīng)用后我們?cè)俅尾榭垂ぷ髫?fù)載的變化：
kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
echoserver本文標(biāo)題：漸進(jìn)式交付組件KruiseRollouts使用
網(wǎng)頁(yè)鏈接：http://www.dlmjj.cn/article/djjsdje.html
