探祕金融級雲原生髮布工做負載 CafeDeployment

時間 2019-12-13

原文原文鏈接

本文做者：螞蟻金服昊天，楓晟node

本文簡單介紹了螞蟻金服 SOFAStack 的 Kubernetes 自定義資源 CafeDeployment 的開發背景和功能特性，咱們將會在6月25日的 KubeConf 上對其作詳細的介紹和演示，歡迎你們來交流。api

背景介紹

Kubernetes 原生社區 Deployment 和 StatefulSet 解決了「服務節點版本一致性」的問題，而且經過 Rolling Update 實現了滾動升級，提供了基本的回滾策略。對於高可用建設要求不高的「年輕」業務，是一個不錯的選擇。安全

可是，在金融場景下，要解決的場景複雜得多。所以咱們在金融分佈式架構-雲應用引擎（SOFAStack-CAFE，參見金融級雲原生探索實踐系列 - 開篇）中提出了 CafeDeployment 的雲原生模型，致力於解決如下問題：bash

1. IP 不可變
架構

對於不少運維體系建設較爲早期的用戶，使用的服務框架、監控、安全策略，大量依賴 IP 做爲惟一標識而被普遍使用。遷移到 Kubernetes 最大的改變就是 IP 會飄，而這對於他們來講，無異於運維、服務框架的推倒重來。app

2. 金融體系下的高可用
框架

Deployment/StatefulSet 沒法根據特定屬性進行差別化部署。而在以同城雙活爲建設基礎的金融領域，爲了強管控 Pod 的部署結構（即保證每一個機房/部署單元都有副本運行），若經過原生組件進行部署，咱們不得不維護多個幾乎如出一轍的 Deployment/StatefulSet，來保證 Pod 必定會飄到指定機房/部署單元的 node 上。在規模上到必定程度後，這無疑加大了運維管控的複雜度和成本。運維

3. 靈活的部署策略分佈式

Deployment 沒法控制發佈步長，StatefulSet 雖然能夠控制步長，可是每次都須要人工計算最新版本須要的副本數並修改 Partition，在多機房/部署單元的狀況下，光想一想發佈要作的操做都腦殼炸裂。ui

在面對以上這些問題的時候，咱們思考：能不能有一個相似 Deployment 的東西，不只能夠實現副本保持，而且能協助用戶管控應用節點部署結構、作 Beta 驗證、分批發布，減小用戶干預流程，實現最大限度減小發布風險的目標，作到快速止損，並進行修正干預。這就是咱們爲何選擇定義了本身的資源——CafeDeployment。

模型定義

CafeDeployment 主要提供跨部署單元的管理功能，其下管理多個 InPlaceSet。每一個 InPlaceSet 對應一個部署單元。部署單元是邏輯概念，他經過 Node 上的 label 來劃分集羣中的節點，而 InPlaceSet 則經過 NodeAffinity 能力，將其下的 Pod 部署到同一個部署單元的機器上。由此實現 CafeDeployment 跨部署單元的管理。

CafeDeployment 做爲多個部署單元的上層，除了提供副本保持，歷史版本維護等基本功能，還提供了跨部署單元的分組擴容，分組發佈，Pod 調度等功能。模型定義以下：

apiVersion: apps.cafe.cloud.alipay.com/v1alpha1
kind: CafeDeployment
metadata:
  ......
spec:
  historyLimit: 20
  podSetType: InPlaceSet        # 目前支持底層PodSet：InPlaceSet，ReplicaSet，StatefulSet
  replicas: 10
  selector:
  matchLabels:
    instance: productpage
    name: bookinfo
  strategy:
    batchSize: 4                # 分組發佈時，每組更新的Pod數目
    minReadySeconds: 30
    needWaitingForConfirm: true # 分組發佈中，每組結束時是否須要等待確認
    upgradeType: Beta           # 目前支持發佈策略：Beta發佈，分組發佈
    pause: false
  template:
    ......
  volumeClaimTemplates:         # 用於支持statefulSet
  serviceName:                  # 用於支持statefulSet
  topology:
    autoReschedule:
      enable: true              # 是否啓動Pod自動重調度
      initialDelaySeconds: 10
    unitType: Cell              # 部署單元類型：Cell，Zone，None
    unitReplicas:
      CellA: 4                  # 固定某部署單元的Pod數目
    values:                     # 部署單元
      - CellA
      - CellB複製代碼

由於咱們將大部分的控制邏輯都抽取到上層 CafeDeployment 中，所以咱們從新設計了 InPlaceSet，將它作得足夠簡單，只關注於「InPlace」相關的功能，即副本保持和原地升級，保持 IP 不變的能力，模型定義以下：

spec:
  minReadySeconds: 30
  replicas: 6
  selector:
    matchLabels:
      instance: productpage
      name: bookinfo
      deployUnit: CellB
  strategy:
    partition: 6    # 控制發佈時更新Pod的進度
  template:
    ......複製代碼

功能特性

靈活的分組定義

CafeDeployment 支持跨部署單元的分組擴容，Pod 調度，分組發佈。分組策略主要分爲兩種，Beta 分組和 Batch 分組：

Batch 分組

即根據 BatchSize 將 Pod 分爲多個批次，每批中的 Pod 會同時發佈。待用戶確認（needWaitingForConfirm=true時）無誤時，或當前批次全部 Pod 都 ready 後（needWaitingForConfirm=false 時），則會開始進行下一組的發佈。

在分組暫停時，CafeDeployment 會被打上 Annotation: cafe.sofastack.io/upgrade-confirmed=false，用戶可經過將 Annotation 的值改成 true，確認當前分組。

Beta 分組

相比 Batch 發佈，會在第一組發佈以前多一步 Beta 分組。此組會在每一個部署單元內選擇一個 Pod 進行發佈，以減少錯誤配置帶來的影響。若用戶確認無誤，能夠確認繼續，以進入正常的 Batch 發佈流程。

安全的分組擴容和發佈能力

分組擴容

爲預防不正確的配置形成大量錯誤 Pod 同時建立，佔用大量資源等意外狀況出現，CafeDeployment 支持分組擴容，以下降風險。

在以下配置時，CafeDeployment 會建立兩個 InPlaceSet 實例，並開始分組建立（擴容）Pod。

spec:
  ......
  replicas: 10                  # 副本數爲10
  strategy:
    upgradeType: Beta           # Beta發佈
    batchSize: 4                # 每組Pod數爲4
    needWaitingForConfirm: true # 分組暫停
  topology:
    ......
    values:                     # 兩個部署單元，CellA和CellB
      - CellA
      - CellB複製代碼

初始時，InPlaceSet 的 replicas 和 partition 都爲 0，CafeDeployment 會在以後默認將 10 個 Pod 均分到兩個部署單元中，並參考 Beta 發佈和 BatchSize 配置，分紅 3 組進行，以下圖所示。

第一組，爲 Beta 分組，會在兩個部署單元中各建立一個 Pod。待 Pod 都 ready 後，會要求用戶進行確認，方可繼續第二組。

第二組，爲普通發佈，由於 BatchSize=4，因此會在兩個部署單元中各建立 2 個 Pod。以後一樣須要通過用確認纔會繼續進入第三組。若 CafeDeployment 中的配置 needWaitingForConfirm=false，則在當前批次的全部 Pod 都 ready 後，會自動進入下一組的發佈。

第三組，爲最後一組發佈，當全部 Pod 都 ready 後，則會結束當前發佈。

發佈過程當中若出現問題，可經過修改 CafeDeployment 的 replicas 值等方式結束當前發佈。

分組發佈

當修改 CafeDeployment 中的 PodTemplate 裏的相關配置後，就會觸發發佈流程。目前一樣支持 Beta 發佈和 Batch 發佈兩種類型。當 CafeDeployment 有以下配置時，CafeDeployment 的 10 個 Pod 會被分到三組中進行發佈。

spec:
  ......
  replicas: 10                  # 副本數爲10
  strategy:
    upgradeType: Beta           # Beta發佈
    batchSize: 4                # 每組Pod數爲4
    needWaitingForConfirm: true # 分組暫停
  topology:
    ......
    values:                     # 兩個部署單元，CellA和CellB
      - CellA
      - CellB複製代碼

第一組爲 Beta 分組，每一個部署單元會選擇一個 Pod 進行發佈。

第二組和第三組各有 4 個 Pod。

若當前 Pod 在部署單元的分配不均勻，以下圖所示，CafeDeploymentController 也會負責計算並分配對應的配額給兩個部署單元，來對發佈進度進行統一的調度。

若是配置了分組暫停，則每組結束後都會須要用戶進行確認。

Pod 發佈與外部的通訊機制

使用 Readiness Gate 做爲 Pod 是否能夠承載外部流量的標識。在發佈前，經過將 Readiness Gate 設置爲 False，使得當前 Pod IP 在 Endpoint 上從 addresses 列表轉移到 notReadyAddresses 列表；在發佈完成後，將 Readiness Gate 設置爲 True，Pod IP 在 Endpoint 上又會從 notReadyAddresses 轉移到 addresses。相關流量組件經過 Watch Endpoint 上地址變化完成切流和引流，並經過 finalizer 對 Pod 進行打標保護。

自適應的 Pod 重調度

在建立 Pod 的過程當中，可能會遇到某個部署單元資源不足的狀況，新的 Pod 會一直 Pending。這時若是打開自動重調度功能（以下所示），則 CafeDeploymentController 會嘗試將 Pod 分配到其餘未出現資源緊張的部署單元上。

spec:
  topology:
    autoReschedule:
      enable: true            # 是否啓動Pod自動重調度
      initialDelaySeconds: 10 # Pod因爲資源不足，10秒後會被嘗試重調度複製代碼

在 Pod 部署過程當中，以下圖所示，

若是在最後一批分組發佈的時候，出現 Pod 因資源不足而沒法啓動的狀況，則 CafeDeploymentController 會自動將此 Pod 的配額調度到其餘的資源充足的部署單元中。

固然，CafeDeployment 也支持手動指定 Pod 的分配方案，經過修改以下相關配置能夠進行精確的指定：

spec:
  topology:
    ......
    unitReplicas:
      CellA: 4    # 固定某部署單元的Pod數目
      CellB: 10%  # 經過百分比指定
    values:
      - CellA
      - CellB
      - CellC複製代碼

這時，CafeDeploymentController 會優先根據指定方案進行 Pod 分配。

可適配多種社區工做負載

CafeDeploymentController 自己只提供了發佈策略和跨部署單元管理的一個抽象實現，它對底層的 Pod 集合是經過 PodSetControlInterface 接口來控制。所以，經過對此接口的不一樣實現，能夠保證對接多種 workload。目前已經實現了與 InPlaceSet 和 ReplicaSet 的對接，對 StatefulSet 的對接也在進行中。

由於 CafeDeployment 只負責各類策略的實現，因此並不會對 Kubernetes 原生的功能有任何入侵。ReplicaSetController，StatefulSetController 會繼續履行他們以前的職責，保證各自的特性。

總結

CafeDeployment 的設計與實現，並不是一日之功，咱們走過彎路，也受到過質疑。但咱們仍然堅信，在金融場景下須要這樣的一種工做負載，由於不管是 Deployment、StatefulSet 仍是 InPlaceSet，爲了實現高可用和無損發佈，都無疑須要付出比 apply yaml 更多的精力，而這些每每都不是一個業務開發所關心的。

目前，CafeDeployment所提供的各類發佈策略，靈活的分組發佈，高可用和無損升級的能力已成爲了金融雲應用發佈的重要一環，爲產品層提供容器雲原生的部署能力，並給咱們用戶的生產力和效率帶來極大提高。後續咱們將會繼續加強 CafeDeployment 的能力，好比提供更靈活的自定義拓撲結構、機房/部署單元內更靈活的部署策略以知足更多的高可用發佈場景的需求等。

KubeCon + CloudNativeCon | Open Source Summit 2019 中國論壇

分享主題：《爲互聯網金融關鍵任務場景擴展部署》-螞蟻金服

分享嘉賓：

Mengyi Zhou：Mengyi Zhou is a software engineer at PaaS cloud service team of Ant Financial, where she focuses on building large-scale deployment platform for both vm and container services on cloud. She indulges herself into devops workflow and experience. She is one of the core developer of AntCloud kubernetes service.

Ke Wu：Ke Wu is a Senior Engineer from Ant Financial. Ke works in Ant Financial PaaS cloud service team, with a focus on AntCloud Kubernetes Service development including extending Kubernetes for financial scenario. Ke has worked on PaaS and Big Data for years. He is also a contributor of Kubernetes.

活動時間：2019.6.25

詳情請戳「這裏」。

公衆號：金融級分佈式架構（Antfin_SOFA）