邊開飛機邊換引擎？咱們造了個新功能保障業務流量無損遷移

做者 | 顧靜（子白）
來源 | 阿里巴巴雲原生公衆號

容器化部署應用能夠下降企業成本，提高研發效率，解放運維人員。據 Gartner 預計，到 2022 年，將有 75％ 的企業將在生產中運行容器化應用程序。Kubernetes 是企業部署容器化應用的首選框架。因爲 Kubernetes 部署及運維的複雜性，愈來愈多的客戶選擇將業務從 ECS 或者自建的 Kubernetes 遷移到阿里雲託管版 Kubernetes —— ACK 中。可是，如何保證業務流量的平滑遷移成爲一大挑戰。

Cloud Controller Manager（CCM）是 ACK 的一個系統核心組件，負責對接 Kubernetes 與雲上基礎產品如 CLB、VPC、DNS 等。當 Service 的類型設置爲 Type=LoadBalancer 時，CCM 會爲該 Service 建立或配置阿里雲負載均衡 CLB。當 Service 對應的後端 Endpoint 或者集羣節點發生變化時，CCM 會自動更新 CLB 的後端虛擬服務器組。此外，CCM 還提供了許多阿里雲註解，支持豐富的負載均衡能力。

近期 CCM 發佈了一個新特性——支持在同一個 CLB 後端掛載集羣內節點和集羣外 ECS，藉助這一特性能夠解決業務容器化過程當中流量平滑遷移的難題。

場景一：應用容器化改造（流量平滑遷移）

對於一個 CLB，支持將流量轉發至集羣內及集羣外節點

1）操做步驟

• 登陸 CLB 控制檯建立 CLB，記錄 CLB ID ("lb-xxxxx")
• 建立 Service

設置 service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners 爲 false，無論理監聽信息。

CCM 會自動建立對應的虛擬服務器組。

cat <<EOF |kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "lb-xxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners: "false"
  labels:
    app: nignx
  name: my-nginx-svc
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
EOF

• 登陸 CLB 控制檯，建立監聽並關聯虛擬服務器組
• 登陸 CLB 控制檯，手動在虛擬服務器組中添加集羣外 ECS 並設置權重

2）預期結果

配置完成後，在 CLB 的虛擬服務組裏既能夠看到集羣內的節點，也能夠看到集羣外的 ECS。集羣內應用進行擴縮容時，集羣外的 ECS 節點不受影響。

場景二：金絲雀發佈

支持金絲雀發佈，將流量按比例轉發至集羣內及集羣外節點

遷移過程當中，每每須要逐步將流量從存量 ECS 遷往 Kubernetes 集羣中。CCM 支持經過 annotationservice.beta.kubernetes.io/alicloud-loadbalancer-weight爲 Kubernetes 集羣配置權重，從而實現流量的逐步遷移。

1）注意事項

• 不能跨 CLB 複用虛擬服務器組
• 一個虛擬服務器組只能與一個端口關聯
• 集羣內節點權重由 CCM 組件設置，集羣外 ECS 權重須要用戶手動設置

2）操做步驟

• 登陸 CLB 控制檯建立 CLB、監聽及虛擬服務器組，記錄 CLB ID ("lb-xxxx") 及虛擬服務器組 Id ("rsp-xxx")
• 手動在虛擬服務器組中添加集羣外 ECS 並設置權重
• 建立 Service

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    # 集羣內部權重爲20%
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: nginx-svc
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

3）預期結果

配置完成後，在 CLB 的虛擬服務組裏既能夠看到集羣內的節點，也能夠看到集羣外的 ECS，集羣節點的權重按照 annotation 配置。集羣內應用進行擴縮容時，集羣外的 ECS 節點不受影響。

場景三：多集羣業務流量多活與災備

對於一個 CLB，支持將流量轉發至多個 Kubernetes 集羣內

企業用戶會採起多種措施以保障應用的高可用性，如建立多個集羣進行備份、容災等。這要求業務流量能夠經過一個 CLB 接入多個 Kubernetes 集羣中，而且支持爲 Kubernetes 集羣設置不一樣的權重，以下圖所示。

1）注意事項

• 不能跨 CLB 複用虛擬服務器組
• 一個虛擬服務器組只能與一個端口關聯
• 兩個集羣均已配置 Cluster Id，不然兩個集羣中的 service 須要不一樣名稱

2）操做步驟

• 登陸 CLB 控制檯建立 CLB、監聽及虛擬服務器組，記錄 CLB ID ("lb-xxxx")  及虛擬服務器組 Id ("rsp-xxx")
• 集羣 A 中建立 Serivce-A，權重設置爲 20%

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: service-A
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

3）預期結果

配置完成後，在 clb 的虛擬服務組裏既能夠看到集羣 A 內的節點，也能夠看到集羣 B 的節點。集羣節點的權重按照 annotation 自動設置。集羣內應用進行擴縮容時，CLB 後端虛擬服務器組會自動更新。

總結

出於降本增效的考慮，愈來愈多的企業採用容器化方式部署應用。在業務遷移過程當中，如何保障業務流量不受損成爲一大難題。對於電商類應用而言，業務流量下跌每每會致使交易量下跌，形成重大損失。遊戲類應用對業務流量也十分敏感，短暫的流量中斷都會明顯地影響遊戲用戶體驗；交通類應用的流量下跌會影響交通流量管制、交通故障排險效率。保障業務流量不受損是保障用戶業務正常運轉的底線。

CCM 發佈的支持在同一個 CLB 後端掛載集羣內節點和集羣外 ECS 的功能，能夠一舉解決遷移過程當中流量中斷的難題。同時，還支持將業務流量轉發至多個 Kubernetes 集羣內，支撐備份、容災等需求，保障業務高可用。