灰度發布

逐步擴大新版本的發布范圍，從少量用戶逐步擴展到全體用戶。
特點是分階段發布、持續監控、逐步擴展
適合需要逐步驗證和降低風險的更新

金絲雀部署

將新版本先部署到一小部分用戶或服務器，觀察其表現，再決定是否全面推廣。
特點：小范圍部署、實時監控、快速回滾
適合高風險更新或需要快速驗證的情況。

灰度發布和金絲雀部署的關系

包含關系：金絲雀部署是灰度發布的第一階段，先在小范圍內驗證，再逐步擴大。
目標一致：兩者都旨在降低發布風險，確保穩定性。
策略互補：金絲雀部署用于快速驗證，灰度發布用于逐步擴展，常結合使用。

金絲雀驗證

簡單的金絲雀測試一般通過手工測試驗證，復雜的金絲雀測試需要比較完善的監控基礎設施配合，通過監控指標反饋，觀察金絲雀的健康狀況，作為后續發布或回退的依據。 如果金絲測試通過，則把剩余的V1版本全部升級為V2版本。如果金絲雀測試失敗，則直接回退金絲雀，發布失敗。

優點：靈活，策略自定義，可以按照流量或具體的內容進行灰度(比如不同賬號，不同參數)，出現問題不會影響全網用戶
缺點：沒有覆蓋到所有的用戶導致出現問題不好排查

1. 創建一個deployment，pod鏡像使用版本v1

vi canary-v1.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-v1
spec:replicas: 5selector:matchLabels:app: myappversion: v1template:metadata:labels:app: myappversion: v1spec:containers:- name: myappimage: 172.16.80.140/myapp/myapp:v1imagePullPolicy: IfNotPresentports:- containerPort: 80

2. 執行命令，更改版本，進行金絲雀部署

kubectl set image deployment myapp-v1 myapp=172.16.80.140/myapp/myapp:v2  && kubectl rollout pause deployment myapp-v1

新生成的pod，已經變成了新的版本
業務運行一段時候，版本沒有問題，可以取消暫停完全部署

kubectl rollout resume deployment myapp-v1

pod都變成了新版本，并且數量也與deploy設置的相同
rs變成了兩個，老版本的rs和新版本的共存，可以隨時rollingupdate

4. pod變化分析

5. 居觀察這種簡單命令的金絲雀部署pod變化，應該是根據maxSurge和maxUnvaliable調整的
   默認都是25%
   當副本是5時，pod最多是 5 + 525% = 6.25，向上取整，所以最多有7個
   pod不可用數量是 5 - 525% = 3.75，向下取整為3，所以可用的4個，不可用的1個會被干掉
   總數為7，所以有 7 - 4 = 3 個新版本的pod
   以上分析只是猜測，官網沒有找到具體說明，修改測試了幾次都符合這個規律，是否正確還請指正

6. 以上只是金絲雀發布的一種比較簡單的方式，具體可參考官網通過修改yaml文件實現