您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關在Kubernetes上如何部署Argo Rollouts和Ambassador進行灰度發布的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
Ambassador API 網關與 Argo 集成
灰度發布(金絲雀發布/Canary)是一種強大的策略,通過增量地向用戶子集發布軟件的新版本來降低生產風險。假設你推出了服務的 v1.1 版本,但它有一個 bug。不是立即將它暴露給所有的流量,而是通過將 v1.1 暴露給流量的一個子集(例如 5%)來開始發布過程。隨著時間的推移,你的流量逐漸增加到 100%。在此期間,任何暴露的 bug 都僅限于你的用戶子集。
雖然理論上很簡單,但在實踐中使用灰度發布需要將 CI 流水線與持續部署工作流(如 Argo)集成在一起,并使用 API 網關來管理到服務的流量。
Ambassador 是一個基于 Envoy 代理構建的開源 kubernetes 原生 API 網關和入口控制器。Ambassador 的常見用例包括路由 gRPC 流量、認證和速率限制。雖然 Ambassador 支持標準的 ingress 類,但大多數用戶使用 Ambassador mapping 資源。mapping 資源定義了路由并支持大量的屬性集,超出了 ingress 支持的標準集。下面是一個 mapping 示例:
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
name: echo
spec:
prefix: /echo
rewrite: /echo
service: echo-stable:80
我們已經在 Argo Rollouts 和 Ambassador 之間建立了一個原生集成(代碼)[1]。你現在可以創建一個 Rollout 資源來引用 Ambassador mapping:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: echo-rollout
annotations:
spec:
replicas: 5
revisionHistoryLimit: 2
selector:
matchLabels:
app: echo
template:
metadata:
labels:
app: echo
spec:
containers:
- image: hashicorp/http-echo
args:
- "-text=VERSION 137"
- -listen=:8080
imagePullPolicy: Always
name: echo-v1
ports:
- containerPort: 8080
strategy:
canary:
stableService: echo-stable
canaryService: echo-canary
trafficRouting:
ambassador:
mapping:
- echo
steps:
- setWeight: 20
- pause: {duration: 10s}
- setWeight: 50
- pause: {duration: 10s}
- setWeight: 100
- pause: {duration: 10}
請注意上面粗體部分,它引用了上面定義的名為 echo 的 Ambassador mapping 資源。將這些配置應用到集群將啟動 echo-canary 服務,該服務將把 20%的流量路由到 canary,持續 10 秒,然后在 10 秒內提升到 50%,然后再提升到 100%。
感謝各位的閱讀!關于“在Kubernetes上如何部署Argo Rollouts和Ambassador進行灰度發布”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。