作者 | 王思宇（酒祝）
Photo Creidt@ 王思宇（酒祝）

背景

?
OpenKruise 是阿里云開源的云原生應(yīng)用自動化管理套件，也是當(dāng)前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 項目。它來自阿里巴巴多年來容器化、云原生的技術(shù)沉淀，是阿里內(nèi)部生產(chǎn)環(huán)境大規(guī)模應(yīng)用的基于 Kubernetes 之上的標準擴展組件，也是緊貼上游社區(qū)標準、適應(yīng)互聯(lián)網(wǎng)規(guī)模化場景的技術(shù)理念與最佳實踐。
?
OpenKruise 在 2021 年 5 月 20 日發(fā)布了最新的 v0.9.0 版本（ChangeLog?），新增了 Pod 容器重啟、資源級聯(lián)刪除防護等重磅功能，本文以下對新版本做整體的概覽介紹。
?

Pod 容器重啟/重建

?
“重啟” 是一個很樸素的需求，即使日常運維的訴求，也是技術(shù)領(lǐng)域較為常見的 “恢復(fù)手段”。而在原生的 Kubernetes 中，并沒有提供任何對容器粒度的操作能力，Pod 作為最小操作單元也只有創(chuàng)建、刪除兩種操作方式。
?
有的同學(xué)可能會問，在云原生時代，為什么用戶還要關(guān)注容器重啟這種運維操作呢？在理想的 Serverless 模式下，業(yè)務(wù)只需要關(guān)心服務(wù)自身就好吧？
?
這來自于云原生架構(gòu)和過去傳統(tǒng)基礎(chǔ)基礎(chǔ)設(shè)施的差異性。在傳統(tǒng)的物理機、虛擬機時代，一臺機器上往往會部署和運行多個應(yīng)用的實例，并且機器和應(yīng)用的生命周期是不同的；在這種情況下，應(yīng)用實例的重啟可能僅僅是一條 systemctl 或 supervisor 之類的指令，而無需將整個機器重啟。然而，在容器與云原生模式下，應(yīng)用的生命周期是和 Pod 容器綁定的；即常規(guī)情況下，一個容器只運行一個應(yīng)用進程，一個 Pod 也只提供一個應(yīng)用實例的服務(wù)。
?
基于上述的限制，目前原生 Kubernetes 之下是沒有 API 來為上層業(yè)務(wù)提供容器（應(yīng)用）重啟能力的。而 Kruise v0.9.0 版本提供了一種單 Pod 維度的容器重啟能力，兼容 1.16 及以上版本的標準 Kubernetes 集群。在安裝或升級 Kruise? 之后，只需要創(chuàng)建 ContainerRecreateRequest（簡稱 CRR） 對象來指定重啟，最簡單的 YAML 如下：

apiVersion: apps.kruise.io/v1alpha1 kind: ContainerRecreateRequest metadata:namespace: pod-namespacename: xxx spec:podName: pod-namecontainers:- name: app- name: sidecar

?
其中，namespace 需要與要操作的 Pod 在同一個命名空間，name 可自選。spec 中 podName 是 Pod 名字，containers 列表則可以指定 Pod 中一個或多個容器名來執(zhí)行重啟。
?
除了上述必選字段外，CRR 還提供了多種可選的重啟策略：
?

spec:# ...strategy:failurePolicy: FailorderedRecreate: falseterminationGracePeriodSeconds: 30unreadyGracePeriodSeconds: 3minStartedSeconds: 10activeDeadlineSeconds: 300ttlSecondsAfterFinished: 1800

• failurePolicy：Fail 或 Ignore，默認 Fail；表示一旦有某個容器停止或重建失敗，CRR 立即結(jié)束。
• orderedRecreate：默認 false；true 表示列表有多個容器時，等前一個容器重建完成了，再開始重建下一個。
• terminationGracePeriodSeconds：等待容器優(yōu)雅退出的時間，不填默認用 Pod 中定義的時間。
• unreadyGracePeriodSeconds：在重建之前先把 Pod 設(shè)為 not ready，并等待這段時間后再開始執(zhí)行重建。
  • 注：該功能依賴于 KruisePodReadinessGate 這個 feature-gate 要打開，后者會在每個 Pod 創(chuàng)建的時候注入一個 readinessGate。否則，默認只會給 Kruise workload 創(chuàng)建的 Pod 注入 readinessGate，也就是說只有這些 Pod 才能在 CRR 重建時使用 unreadyGracePeriodSeconds。
• minStartedSeconds：重建后新容器至少保持運行這段時間，才認為該容器重建成功。
• activeDeadlineSeconds：如果 CRR 執(zhí)行超過這個時間，則直接標記為結(jié)束（未完成的容器標記為失敗）。
• ttlSecondsAfterFinished：CRR 結(jié)束后，過了這段時間自動被刪除掉。

實現(xiàn)原理：當(dāng)用戶創(chuàng)建了 CRR 后，經(jīng)過了 kruise-manager 中心端的初步處理，會被 Pod 所在節(jié)點上的 kruise-daemon 收到并開始執(zhí)行。執(zhí)行的過程如下：
?

如果 Pod 容器定義了 preStop，kruise-daemon 會先走 CRI 運行時 exec 到容器中執(zhí)行 preStop。

如果沒有 preStop 或執(zhí)行完成，kruise-daemon 調(diào)用 CRI 接口將容器停止。

kubelet 感知到容器退出，則會新建一個 “序號” 遞增的新容器，并開始啟動（以及執(zhí)行 postStart）。

kruise-daemon 感知到新容器啟動成功，上報 CRR 重啟完成。

上述的容器 “序號” 其實就對應(yīng)了 Pod status 中 kubelet 上報的 restartCount。因此，在容器重啟后會看到 Pod 的 restartCount 增加。另外，因為容器發(fā)生了重建，之前臨時寫到舊容器 rootfs 中的文件會丟失，但是 volume mount 掛載卷中的數(shù)據(jù)仍然存在。
?

級聯(lián)刪除防護

?
Kubernetes 的面向終態(tài)自動化是一把 “雙刃劍”，它既為應(yīng)用帶來了聲明式的部署能力，同時也潛在地會將一些誤操作行為被終態(tài)化放大。例如它的 “級聯(lián)刪除” 機制，即正常情況（非 orphan 刪除）下一旦父類資源被刪除，則所有子類資源都會被關(guān)聯(lián)刪除：
?

刪除一個 CRD，其所有對應(yīng)的 CR 都被清理掉。

刪除一個 namespace，這個命名空間下包括 Pod 在內(nèi)所有資源都被一起刪除。

刪除一個 workload（Deployment/StatefulSet/…），則下屬所有 Pod 被刪除。

類似這種 “級聯(lián)刪除” 帶來的故障，我們已經(jīng)聽到不少社區(qū) K8s 用戶和開發(fā)者帶來的抱怨。對于任何一家企業(yè)來說，其生產(chǎn)環(huán)境發(fā)生這種規(guī)模誤刪除都是不可承受之痛，阿里巴巴也不例外。
?
因此，在 Kruise v0.9.0 版本中，我們將阿里內(nèi)部所做的防級聯(lián)刪除能力輸出到社區(qū)，期望能為更多的用戶帶來穩(wěn)定性保障。在當(dāng)前版本中如果需要使用該功能，則在安裝或升級 Kruise 的時候需要顯式打開 ResourcesDeletionProtection 這個 feature-gate。
?
對于需要防護刪除的資源對象，用戶可以給其打上 policy.kruise.io/delete-protection 標簽，value 可以有兩種：
?

• Always: 表示這個對象禁止被刪除，除非上述 label 被去掉。
• Cascading：這個對象如果還有可用的下屬資源，則禁止被刪除。

目前支持的資源類型、以及 cascading 級聯(lián)關(guān)系如下：
?

CloneSet 新增功能

?

1. 刪除優(yōu)先級

?
controller.kubernetes.io/pod-deletion-cost? 是從 Kubernetes 1.21 版本后加入的 annotation，ReplicaSet 在縮容時會參考這個 cost 數(shù)值來排序。CloneSet 從 Kruise v0.9.0 版本后也同樣支持了這個功能。
?
用戶可以把這個 annotation 配置到 pod 上，它的 value 數(shù)值是 int 類型，表示這個 pod 相較于同個 CloneSet 下其他 pod 的 “刪除代價”，代價越小的 pod 刪除優(yōu)先級相對越高。沒有設(shè)置這個 annotation 的 pod 默認 deletion cost 是 0。
?
注意這個刪除順序并不是強制保證的，因為真實的 pod 的刪除類似于下述順序：
?

未調(diào)度 < 已調(diào)度

PodPending < PodUnknown < PodRunning

Not ready < ready

較小 pod-deletion cost < 較大 pod-deletion cost

處于 Ready 時間較短 < 較長

容器重啟次數(shù)較多 < 較少

創(chuàng)建時間較短 < 較長

2. 配合原地升級的鏡像預(yù)熱

?
當(dāng)使用 CloneSet 做應(yīng)用原地升級時，只會升級容器鏡像、而 Pod 不會發(fā)生重建。這就保證了 Pod 升級前后所在 node 不會發(fā)生變化，從而在原地升級的過程中，如果 CloneSet 提前在所有 Pod 節(jié)點上先把新版本鏡像拉取好，則在后續(xù)的發(fā)布批次中 Pod 原地升級速度會得到大幅度提高。
?
在當(dāng)前版本中如果需要使用該功能，則在安裝或升級 Kruise 的時候需要顯式打開 PreDownloadImageForInPlaceUpdate 這個 feature-gate。打開后，當(dāng)用戶更新了 CloneSet template 中的鏡像、且發(fā)布策略支持原地升級，則 CloneSet 會自動為這個新鏡像創(chuàng)建 ImagePullJob 對象（OpenKruise 提供的批量鏡像預(yù)熱功能），來提前在 Pod 所在節(jié)點上預(yù)熱新鏡像。
?
默認情況下 CloneSet 給 ImagePullJob 配置的并發(fā)度是 1，也就是一個個節(jié)點拉鏡像。如果需要調(diào)整，你可以在 CloneSet annotation 上設(shè)置其鏡像預(yù)熱時的并發(fā)度：
?

apiVersion: apps.kruise.io/v1alpha1 kind: CloneSet metadata:annotations:apps.kruise.io/image-predownload-parallelism: "5"

?

3. 先擴再縮的 Pod 置換方式

?
在過去版本中，CloneSet 的 maxUnavailable、maxSurge 策略只對應(yīng)用發(fā)布過程生效。而從 Kruise v0.9.0 版本開始，這兩個策略同樣會對 Pod 指定刪除生效。
?
也就是說，當(dāng)用戶通過 podsToDelete 或 apps.kruise.io/specified-delete: true 方式（具體見官網(wǎng)文檔）來指定一個或多個 Pod 期望刪除時，CloneSet 只會在當(dāng)前不可用 Pod 數(shù)量（相對于 replicas 總數(shù)）小于 maxUnavailable 的時候才執(zhí)行刪除。同時，如果用戶配置了 maxSurge 策略，則 CloneSet 有可能會先創(chuàng)建一個新 Pod、等待新 Pod ready、再刪除指定的舊 Pod。
?
具體采用什么樣的置換方式，取決于當(dāng)時的 maxUnavailable 和實際不可用 Pod 數(shù)量。比如：
?

• 對于一個 CloneSet maxUnavailable=2, maxSurge=1 且有一個 pod-a 處于不可用狀態(tài)， 如果你對另一個 pod-b 指定刪除， 那么 CloneSet 會立即刪除它，然后創(chuàng)建一個新 Pod。
• 對于一個 CloneSet maxUnavailable=1, maxSurge=1 且有一個 pod-a 處于不可用狀態(tài)， 如果你對另一個 pod-b 指定刪除， 那么 CloneSet 會先新建一個 Pod、等待它 ready，最后再刪除 pod-b。
• 對于一個 CloneSet maxUnavailable=1, maxSurge=1 且有一個 pod-a 處于不可用狀態(tài)， 如果你對這個 pod-a 指定刪除， 那么 CloneSet 會立即刪除它，然后創(chuàng)建一個新 Pod。
• …

4. 基于 partition 終態(tài)的高效回滾

?
在原生的 workload 中，Deployment 自身發(fā)布不支持灰度發(fā)布，StatefulSet 有 partition 語義來允許用戶控制灰度升級的數(shù)量；而 Kruise workload 如 CloneSet、Advanced StatefulSet，也都提供了 partition 來支持灰度分批。
?
對于 CloneSet，Partition 的語義是保留舊版本 Pod 的數(shù)量或百分比。比如說一個 100 個副本的 CloneSet，在升級鏡像時將 partition 數(shù)值階段性改為 80 -> 60 -> 40 -> 20 -> 0，則完成了分 5 批次發(fā)布。
?
但過去，不管是 Deployment、StatefulSet 還是 CloneSet，在發(fā)布的過程中如果想要回滾，都必須將 template 信息（鏡像）重新改回老版本。后兩者在灰度的過程中，將 partition 調(diào)小會觸發(fā)舊版本升級為新版本，但再次 partition 調(diào)大則不會處理。
?
從 v0.9.0 版本開始，CloneSet 的 partition 支持了 “終態(tài)回滾” 功能。如果在安裝或升級 Kruise 的時候打開了 CloneSetPartitionRollback 這個 feature-gate，則當(dāng)用戶將 partition 調(diào)大時，CloneSet 會將對應(yīng)數(shù)量的新版本 Pod 重新回滾到老版本。
?
這樣帶來的好處是顯而易見的：在灰度發(fā)布的過程中，只需要前后調(diào)節(jié) partition 數(shù)值，就能靈活得控制新舊版本的比例數(shù)量。但需要注意的是，CloneSet 所依據(jù)的 “新舊版本” 對應(yīng)的是其 status 中的 updateRevision 和 currentRevision：
?

• updateRevision：對應(yīng)當(dāng)前 CloneSet 所定義的 template 版本。
• currentRevision：該 CloneSet 前一次全量發(fā)布成功的 template 版本。

5. 短 hash

?
默認情況下，CloneSet 在 Pod label 中設(shè)置的 controller-revision-hash 值為 ControllerRevision 的完整名字，比如：

apiVersion: v1 kind: Pod metadata:labels:controller-revision-hash: demo-cloneset-956df7994

它是通過 CloneSet 名字和 ControllerRevision hash 值拼接而成。通常 hash 值長度為 8~10 個字符，而 Kubernetes 中的 label 值不能超過 63 個字符。因此 CloneSet 的名字一般是不能超過 52 個字符的，如果超過了，則無法成功創(chuàng)建出 Pod。
?
在 v0.9.0 版本引入了 CloneSetShortHash 新的 feature-gate。如果它被打開，CloneSet 只會將 Pod 中的 controller-revision-hash 的值只設(shè)置為 hash 值，比如 956df7994，因此 CloneSet 名字的長度不會有任何限制了。（即使啟用該功能，CloneSet 仍然會識別和管理過去存量的 revision label 為完整格式的 Pod。）
?

SidecarSet

?

sidecar 熱升級功能

?
SidecarSet 是 Kruise 提供的獨立管理 sidecar 容器的 workload。用戶可以通過 SidecarSet，來在一定范圍的 Pod 中注入和升級指定的 sidecar 容器。
?
默認情況下，sidecar 的獨立原地升級是先停止舊版本的容器，然后創(chuàng)建新版本的容器。這種方式更加適合不影響Pod服務(wù)可用性的sidecar容器，比如說日志收集 agent，但是對于很多代理或運行時的 sidecar 容器，例如 Istio Envoy，這種升級方法就有問題了。Envoy 作為 Pod 中的一個代理容器，代理了所有的流量，如果直接重啟升級，Pod 服務(wù)的可用性會受到影響。如果需要單獨升級 envoy sidecar，就需要復(fù)雜的 grace 終止和協(xié)調(diào)機制。所以我們?yōu)檫@種 sidecar 容器的升級提供了一種新的解決方案，即熱升級（hot upgrade）。
?

apiVersion: apps.kruise.io/v1alpha1 kind: SidecarSet spec:# ...containers:- name: nginx-sidecarimage: nginx:1.18lifecycle:postStart:exec:command:- /bin/bash- -c- /usr/local/bin/nginx-agent migrateupgradeStrategy:upgradeType: HotUpgradehotUpgradeEmptyImage: empty:1.0.0

• upgradeType: HotUpgrade代表該sidecar容器的類型是hot upgrade，將執(zhí)行熱升級方案hotUpgradeEmptyImage: 當(dāng)熱升級sidecar容器時，業(yè)務(wù)必須要提供一個empty容器用于熱升級過程中的容器切換。empty容器同sidecar容器具有相同的配置（除了鏡像地址），例如：command, lifecycle, probe等，但是它不做任何工作。
• lifecycle.postStart: 狀態(tài)遷移，該過程完成熱升級過程中的狀態(tài)遷移，該腳本需要由業(yè)務(wù)根據(jù)自身的特點自行實現(xiàn)，例如：nginx熱升級需要完成Listen FD共享以及流量排水（reload）。

具體 sidecar 注入和熱升級流程，請參考官網(wǎng)文檔。

最后

?
了解上述能力的更多信息，可以訪問官網(wǎng)文檔。對 OpenKruise 感興趣的同學(xué)歡迎參與我們的社區(qū)建設(shè)，已經(jīng)使用了 OpenKruise 項目的用戶請在 issue? 中登記。
?

釘釘搜索群號 23330762 加入釘釘交流群！

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的OpenKruise v0.9.0 版本发布：新增 Pod 重启、删除防护等重磅功能的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。