作者 | 酒祝

背景

阿裡雲開源的雲原生應用自動化管理套件、CNCF Sandbox 項目 -- OpenKruise，今天釋出 v0.10.0 新版本，這也會是 OpenKruise v1.0 之前的最後一個 minor 版本。

本文将帶你一覽 v0.10.0 的新變化，其中新增的 WorkloadSpread、PodUnavailableBudget 等大顆粒特性後續還将有轉文詳細介紹其設計實作原理。

新功能概覽

1. WorkloadSpread：旁路的應用彈性拓撲管理能力

在應用部署運維的場景下，有着多種多樣的拓撲打散以及彈性的訴求。其中最常見、最基本的，就是按某種或幾種拓撲水準打散，比如：

應用部署需要按 node 次元打散，避免堆疊（提高容災能力）
應用部署需要按 AZ（available zone）次元打散（提高容災能力）

這些基本的訴求，通過 Kubernetes 原生提供的 pod affinity、topology spread constraints 等能力目前都能夠滿足了。但在實際的生産場景下，還有着太多更加複雜的分區與彈性需求，以下舉一些實際的例子：

按 zone 打散時，需要指定在不同 zone 中部署的比例數，比如某個應用在 zone a、b、c 中部署的 Pod 數量比例為 1 : 1 : 2 等（由于一些現實的原因比如該應用在多個 zone 中的流量不均衡等）
存在多個 zone 或不同機型的拓撲，應用擴容時，優先部署到某個 zone 或機型上，當資源不足時再部署到另一個 zone 或機型上（往後以此類推）；應用縮容時，要按反向順序，優先縮容後面 zone 或機型上的 Pod（往前以此類推）
存在多個基礎的節點池和彈性的節點池，應用部署時需要固定數量或比例的 Pod 部署在基礎節點池，其餘的都擴到彈性節點池

對于這些例子，過去一般隻能将一個應用拆分為多個 Workload（比如 Deployment）來部署，才能解決應用在不同拓撲下采用不同比例數量、擴縮容優先級、資源感覺、彈性選擇等場景的基本問題，但還是需要 PaaS 層深度定制化，來支援對一個應用多個 Workload 的精細化管理。

針對這些問題，在 Kruise v0.10.0 版本中新增了 WorkloadSpread 資源，目前它支援配合 Deployment、ReplicaSet、CloneSet 這些 Workload 類型，來管理它們下屬 Pod 的分區與彈性拓撲。

以下是一個簡化的例子：

apiVersion: apps.kruise.io/v1alpha1
kind: WorkloadSpread
metadata:
  name: workloadspread-demo
spec:
  targetRef:
    apiVersion: apps/v1 | apps.kruise.io/v1alpha1
    kind: Deployment | CloneSet
    name: workload-xxx
  subsets:
  - name: subset-a
    requiredNodeSelectorTerm:
      matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - zone-a
    maxReplicas: 10 | 30%
  - name: subset-b
    requiredNodeSelectorTerm:
      matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - zone-b

建立這個 WorkloadSpread 可以通過 targetRef 關聯到一個 Workload 對象上，然後這個 Workload 在擴容 pod 的過程中，Pod 會被 Kruise 按上述政策注入對應的拓撲規則。這是一種旁路的注入和管理方式，本身不會幹涉 Workload 對 Pod 的擴縮容、釋出管理。

注意：WorkloadSpread 對 Pod 縮容的優先級控制是通過 Pod Deletion Cost 來實作的：

如果 Workload 類型是 CloneSet，則已經支援了這個 feature，可以實作縮容優先級
如果 Workload 類型是 Deployment/ReplicaSet，則要求 Kubernetes version >= 1.21，且在 1.21 中要在 kube-controller-manager 上開啟 PodDeletionCost 這個 feature-gate

使用 WorkloadSpread 功能，需要在安裝/更新 Kruise v0.10.0 的時候打開 WorkloadSpread 這個 feature-gate。

上述例子僅為最簡化配置，更多使用說明請參考官網文檔，具體的實作原理我們将會在後續的文章中與大家分享。

2. PodUnavailableBudget：應用可用性防護

在諸多 Voluntary Disruption 場景中 Kubernetes 原生提供的 Pod Disruption Budget（PDB）通過限制同時中斷的 Pod 數量，來保證應用的高可用性。

但還有很多場景中，即便有 PDB 防護依然将會導緻業務中斷、服務降級，比如：

應用 owner 通過 Deployment 正在進行版本更新，與此同時叢集管理者由于機器資源使用率過低正在進行 node 縮容
中間件團隊利用 SidecarSet 正在原地更新叢集中的sidecar版本（例如：ServiceMesh envoy），同時HPA正在對同一批應用進行縮容
應用 owner 和中間件團隊利用 CloneSet、SidecarSet 原地更新的能力，正在對同一批 Pod 進行更新

這其實很好了解 -- PDB 隻能防控通過 Eviction API 來觸發的 Pod 驅逐（例如 kubectl drain驅逐node上面的所有Pod），但是對于 Pod 删除、原地更新等很多操作是無法防護的。

在 Kruise v0.10.0 版本中新增的 PodUnavailableBudget（PUB）功能，則是對原生 PDB 的強化擴充。它包含了 PDB 自身的能力，并在此基礎上增加了對更多 Voluntary Disruption 操作的防護，包括但不限于 Pod 删除、原地更新等。

apiVersion: apps.kruise.io/v1alpha1
kind: PodUnavailableBudget
metadata:
  name: web-server-pub
  namespace: web
spec:
  targetRef:
    apiVersion: apps/v1 | apps.kruise.io/v1alpha1
    kind: Deployment | CloneSet | StatefulSet | ...
    name: web-server
  # selector 與 targetRef 二選一配置
# selector:
#   matchLabels:
#     app: web-server
  # 保證的最大不可用數量
  maxUnavailable: 60%
  # 保證的最小可用數量
# minAvailable: 40%

使用 PodUnavailableBudget 功能，需要在安裝/更新 Kruise v0.10.0 的時候打開feature-gate（兩個可以選擇打開一個，也可以都打開）：

PodUnavailableBudgetDeleteGate：攔截防護 Pod 删除、驅逐等操作
PodUnavailableBudgetUpdateGate：攔截防護 Pod 原地更新等更新操作

更多使用說明請參考官網文檔，具體的實作原理我們将會在後續的文章中與大家分享。

3. CloneSet 支援按拓撲規則縮容

在 CloneSet 縮容（調小 replicas 數量）的時候，選擇哪些 Pod 删除是有一套固定算法排序的：

未排程 < 已排程
PodPending < PodUnknown < PodRunning
Not ready < ready
較小 pod-deletion cost < 較大 pod-deletion cost
較大打散權重 < 較小
處于 Ready 時間較短 < 較長
容器重新開機次數較多 < 較少
建立時間較短 < 較長

其中，“4” 是在 Kruise v0.9.0 中開始提供的特性，用于支援使用者指定删除順序（WorkloadSpread 就是利用這個功能實作縮容優先級）；而 “5” 則是目前 v0.10.0 提供的特性，即在縮容的時候會參考應用的拓撲打散來排序。

如果應用配置了 topology spread constraints ，則 CloneSet 縮容時會按照其中的 topology 次元打散來選擇 Pod 删除（比如盡量打平多個 zone 上部署 Pod 的數量）
如果應用沒有配置 topology spread constraints ，則預設情況下 CloneSet 縮容時會按照 node 節點次元打散來選擇 Pod 删除（盡量減少同 node 上的堆疊數量）

4. Advanced StatefulSet 支援流式擴容

為了避免在一個新 Advanced StatefulSet 建立後有大量失敗的 pod 被建立出來，從 Kruise v0.10.0 版本開始引入了在 scale strategy 中的 maxUnavailable 政策：

apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
spec:
  # ...
  replicas: 100
  scaleStrategy:
    maxUnavailable: 10% # percentage or absolute number

當這個字段被設定之後，Advanced StatefulSet 會保證建立 pod 之後不可用 pod 數量不超過這個限制值。

比如說，上面這個 StatefulSet 一開始隻會一次性建立 10 個 pod。在此之後，每當一個 pod 變為 running、ready 狀态後，才會再建立一個新 pod 出來。

注意：這個功能隻允許在 podManagementPolicy 是 `Parallel` 的 StatefulSet 中使用。

5. 其他

除了上述内容外，還有一些變動如：

SidecarSet 新增 imagePullSecrets、injectionStrategy.paused 等字段支援配置 sidecar 鏡像拉取 secret 以及暫停注入
Advanced StatefulSet 支援配合原地更新的鏡像提前預熱

詳見 ChangeLog 文檔。

最後

本次的 v0.10.0 會是 OpenKruise v1.0 之前的最後一個 minor 版本，在年底之前 Kruise 将會釋出首個 v1.0 大版本，敬請期待！

另外，OpenKruise 社群開始組織定期的雙周會，從本周四（9月9日）晚上19:00（ GMT+8 Asia/Shanghai）首次開始，本次周會将會講解 v0.10.0 新版本的特性以及 demo 示範。參與方式：

Zoom 會議連結（見文末連結）
加入 OpenKruise 社群交流群（釘釘搜群号 23330762 ），将會有群直播

OpenKruise v0.10.0 版本釋出：新增應用彈性拓撲管理、應用防護等能力背景新功能概覽最後

背景

新功能概覽

1. WorkloadSpread：旁路的應用彈性拓撲管理能力

2. PodUnavailableBudget：應用可用性防護

3. CloneSet 支援按拓撲規則縮容

4. Advanced StatefulSet 支援流式擴容

5. 其他

最後

繼續閱讀

【趨高機器視覺】機器視覺技術原了解析及解決方案

vsftpd dead but subsys locked 的解決方法

CSMA/CD1． CSMA/CD的概述2． CSMA 的工作原理3． CSMA/CD控制規程及特點4． CSMA/CD協定5． CSMA/CD的優點6．結束語

極大似然法(ML)與最大期望法(EM)

C++ 第十五周報告1--《冒泡法排序》

Shell程式設計——sort排序、uniq忽略重複、tr替換壓縮删除、cut指定删除字段、正規表達式元字元sort 指令uniq 指令tr 指令cut 指令正規表達式

筆試面試題目：滑動視窗(二)

Linxu常用指令技巧彙總

httpd服務的部署、啟動、配置和簡單優化一、部署二、啟動三、配置檔案

《Linux指令行與Shell腳本程式設計大全第2版.布盧姆》pdf

資料結構與算法（27）——排序（二）

nginx 安裝錯誤資訊解決

Dijkstra--簡易版（最短路徑）

Ambari介紹和架構原理

GitHub連夜封殺！這份阿裡 10W 字内部 Java 字面試手冊到底有多強？

hdu7108哈希