我們將使用 k8s-native Argo Rollouts 部署控制器和 GitlabCI 來運行到 Kubernetes 的 Canary 部署
本系列文章
- （本文）
- 使用 Istio 進行金絲雀部署
- 使用 Jenkins-X Istio Flagger 進行金絲雀部署
金絲雀部署
我們希望您閱讀 ，我們簡要地解釋了什麼是金絲雀部署。 我們也展示瞭如何使用標準 Kubernetes 資源來實現它。
Argo 推出
Argo Rollouts 是 Kubernetes 原生部署控制器。 它為 Kubernetes 提供了 CRD（自訂資源定義）。 多虧了它，我們可以使用一個新的實體： Rollout，它使用各種配置選項來管理藍綠和金絲雀部署。
自訂資源使用的 Argo Rollouts 控制器
Rollout,允許額外的部署策略，例如 Kubernetes 的藍綠和金絲雀。 資源Rollout提供同等功能Deployment，僅具有額外的部署策略。
資源Deployments有兩種部署策略：RollingUpdateиRecreate。 儘管這些策略適用於大多數情況，但為了大規模部署到伺服器，需要使用其他策略，例如藍綠或金絲雀，這些策略在部署控制器中不可用。 要在 Kubernetes 中使用這些策略，使用者必須在其部署之上編寫腳本。 Argo Rollouts Controller 將這些策略公開為簡單的、聲明性的、可設定的參數。
還有 Argo CI，它提供了一個方便的 Web 介面，可與 Rollouts 一起使用，我們將在下一篇文章中介紹它。
安裝 Argo 部署
服務器端
kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
在我們的基礎設施蘿蔔（見下文）中，我們已經添加了 install.yaml 作為 i/k8s/argo-rollouts/install.yaml。 這樣 GitlabCI 就會將其安裝到叢集中。
客戶端（kubectl 外掛程式）
應用範例
為應用程式程式碼和基礎設施建立單獨的儲存庫是一種很好的做法。
應用程式的儲存庫
這是一個非常簡單的 Python+Flask API，以 JSON 形式回傳回應。 我們將使用 GitlabCI 建置套件並將結果推送到 Gitlab 註冊表。 在註冊表中我們有兩個不同的發行版本：
- wuestkamp/k8s-部署-範例-應用程式：v1
- wuestkamp/k8s-部署-範例-應用程式：v2
它們之間的唯一區別是傳回的 JSON 檔案。 我們使用此應用程式盡可能輕鬆地視覺化我們正在與哪個版本進行通訊。
基礎設施儲存庫
在此儲存庫中，我們將使用 GitlabCI 部署到 Kubernetes，.gitlab-ci.yml 如下所示：
image: traherom/kustomize-dockerbefore_script:
- printenv
- kubectl versionstages:
- deploydeploy test:
stage: deploy
before_script:
- echo $KUBECONFIG
script:
- kubectl get all
- kubectl apply -f i/k8s only:
- master要自己運行它，您需要一個集群，您可以使用 Gcloud：
gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80你需要分叉 並創建一個變數 KUBECONFIG 在 GitlabCI 中，其中將包含存取配置 kubectl 到您的集群。
您可以閱讀有關如何取得叢集 (Gcloud) 憑證的資訊。
基礎設施 YAML
在基礎設施儲存庫中我們有服務：
apiVersion: v1
kind: Service
metadata:
labels:
id: rollout-canary
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancer和 rollout.yaml ：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
replicas: 10
revisionHistoryLimit: 2
selector:
matchLabels:
id: rollout-canary
template:
metadata:
labels:
id: rollout-canary
spec:
containers:
- name: rollouts-demo
image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
imagePullPolicy: Always
strategy:
canary:
steps:
- setWeight: 10
# Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
- pause: {}
- setWeight: 50
- pause: { duration: 120 } # two minutesRollout 與部署的工作方式相同。 如果我們不設定更新策略（例如這裡的金絲雀），它將表現得像預設的滾動更新部署。
我們在 yaml 中定義了金絲雀部署的兩個步驟：
- 10%流量到canary（等待手排OK）
- 前往金絲雀的流量為 50%（等待 2 分鐘，然後繼續達到 100%）
執行初始部署
初始部署後，我們的資源將如下所示：
我們僅從應用程式的第一個版本獲得回應：
執行金絲雀部署
第1步：10%流量
要開始金絲雀部署，我們只需像通常的部署那樣更改映像版本：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
...
template:
metadata:
labels:
id: rollout-canary
spec:
containers:
- name: rollouts-demo
image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...我們推送更改，因此 Gitlab CI 確實進行了部署，並且我們看到了更改：
現在如果我們造訪該服務：
偉大的！ 我們正處於金絲雀部署過程中。 我們可以透過運行來查看進度：
kubectl argo rollouts get rollout rollout-canary
第2步：50%流量：
現在讓我們繼續下一步：重定向 50% 的流量。 我們將此步驟配置為手動運行：
kubectl argo rollouts promote rollout-canary # continue to step 2
我們的應用程式返回了新版本響應的 50%：
以及推出回顧：
精彩的。
第3步：100%流量：
我們將其設定為 2 分鐘後 50% 步驟自動結束並開始 100% 步驟：
以及應用程式輸出：
以及推出回顧：
金絲雀部署完成。
Argo 推出的更多範例
這裡還有更多的例子，例如如何基於canary設定環境預覽和比較：
有關 Argo 推出和 Argo CI 的視頻
我真的推薦這個視頻，它展示了 Argo Rollouts 和 Argo CI 如何協同工作：
總
我真的很喜歡使用 CRD 來管理其他類型的部署或副本集的建立、重定向流量等的想法。 與他們的合作進展順利。 接下來我想測試與 Argo CI 的整合。
然而，Argo CI 和 Flux CI 似乎即將進行大規模合併，所以我可能會等到新版本發布： .
您有 Argo Rollouts 或 Argo CI 的經驗嗎？
也請閱讀我們部落格上的其他文章：
來源： www.habr.com