金絲雀部署是在部分使用者上測試新程式碼的非常有效的方法。 它顯著減少了部署過程中可能出現問題的流量負載,因為它只發生在特定子集中。 本說明專門介紹如何使用 Kubernetes 和部署自動化來組織此類部署。 我們假設您了解 Helm 和 Kubernetes 資源.
Kubernetes 的簡單金絲雀部署包括兩個關鍵資源:服務本身和部署工具。 金絲雀部署透過單一服務進行工作,該服務與服務更新流量的兩個不同資源進行互動。 其中一個資源將適用於「金絲雀」版本,第二個資源將適用於穩定版本。 在這種情況下,我們可以調整金絲雀版本的數量,以減少服務所需的流量。 例如,如果您喜歡使用 Yaml,那麼它在 Kubernetes 中將如下所示:
kind: Deployment
metadata:
name: app-canary
labels:
app: app
spec:
replicas: 1
...
image: myapp:canary
---
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 5
...
image: myapp:stable
---
kind: Service
selector:
app: app # Selector will route traffic to both deployments.
使用 kubectl 更容易想像這個選項,並且在
金絲雀部署自動化
首先,我們需要一個Helm圖表地圖,其中已經包含了我們上面討論的資源。 它應該看起來像這樣:
~/charts/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
Helm 概念的基礎是多版本發布的管理。 穩定版本是我們專案程式碼的主要穩定分支。 但透過 Helm,我們可以使用我們的實驗程式碼部署金絲雀版本。 主要是維持穩定版本和金絲雀版本之間的流量交換。 我們將使用特殊的選擇器來管理這一切:
selector:
app.kubernetes.io/name: myapp
我們的「金絲雀」和穩定的部署資源將在模組上標明此標籤。 如果一切配置正確,那麼在部署 Helm 圖表地圖的金絲雀版本期間,我們將看到流量將被導向到新部署的模組。 該指令的穩定版本如下所示:
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v1 # Goes into app.kubernetes.io/version
--set image.tag=stable
--set replicaCount=5
現在讓我們檢查一下我們的金絲雀版本。 要部署金絲雀版本,我們需要記住兩件事。 版本名稱必須不同,以便我們不會推出目前穩定版本的更新。 版本和標籤也必須不同,以便我們可以部署其他程式碼並透過資源標籤識別差異。
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v2 # Goes into app.kubernetes.io/version
--set image.tag=canary
--set replicaCount=1
就這樣! 如果您 ping 該服務,您可以看到金絲雀更新僅在部分時間路由流量。
如果您正在尋找包含所描述邏輯的部署自動化工具,那麼請注意
來源: www.habr.com