作者 | 王思宇(酒祝)
來源|阿里巴巴云原生公眾號(hào)

得益于 Kubernetes 面向終態(tài)的理念，云原生架構(gòu)天然具備高度自動(dòng)化的能力。然而，面向終態(tài)的自動(dòng)化是一把“雙刃劍”，它既為應(yīng)用帶來了聲明式的部署能力，同時(shí)也潛在地會(huì)將一些誤操作行為被終態(tài)化放大。

因此，充分了解云原生環(huán)境下那些潛在的影響應(yīng)用安全的問題，提前掌握多方位的安全防護(hù)、攔截、限流、熔斷等技術(shù)手段來保障云原生應(yīng)用的運(yùn)行時(shí)穩(wěn)定性至關(guān)重要。

本文整理自作者阿里云容器服務(wù)技術(shù)專家，OpenKruise 作者 & 初創(chuàng)人員之一，Kubernetes、OAM 社區(qū)貢獻(xiàn)者王思宇（酒祝）于 1 月 19 日在阿里云開發(fā)者社區(qū)“周二開源日”的直播分享，介紹了云原生環(huán)境下應(yīng)用安全與可用性的“處處危機(jī)”，分享阿里巴巴保障云原生應(yīng)用運(yùn)行時(shí)穩(wěn)定性經(jīng)驗(yàn)，并且詳細(xì)解讀了后續(xù)這些能力將如何通過 OpenKruise 賦能給開源。

點(diǎn)擊回看完整視頻：https://developer.aliyun.com/live/246065

云原生環(huán)境應(yīng)用安全“危機(jī)”

1. 阿里巴巴云原生應(yīng)用部署結(jié)構(gòu)

這里的云原生應(yīng)用部署結(jié)構(gòu)是在阿里巴巴原生環(huán)境最簡(jiǎn)化的抽象圖，如下圖所示。

首先我們來看幾個(gè) CRD。CloneSet CRD 可以理解成 deployment 的一個(gè) workload，也就是給應(yīng)用部署 Pod 的模板。有了 CloneSet CRD 之后，不同的業(yè)務(wù)以及不同的應(yīng)用會(huì)建立對(duì)應(yīng)的 CloneSet，在 CloneSet 下面再建立對(duì)應(yīng)的 Pod，以及對(duì) Pod 做一些部署、發(fā)布相關(guān)的管理。

除了 CloneSet 之外，還提供了 SidecarSet CRD，這個(gè) CRD 做的事情是在業(yè)務(wù) Pod 創(chuàng)建階段注入 SidecarSetCRD 中定義的 Sidecar 容器。也就是說，在 CloneSet 中業(yè)務(wù)只需要定義 Pod 中的 app 容器，也就是業(yè)務(wù)容器。在 Pod 創(chuàng)建過程中，通過 SidecarSet 在其中定義業(yè)務(wù)中要注入哪些 sidecar 容器。

2. OpenKruise：阿里巴巴應(yīng)用部署基座

開源的 OpenKruise 是阿里巴巴應(yīng)用部署的基座。OpenKruise 提供了多種的 workload。其中包括：CloneSet、Advanced StatefulSet、SidecarSet、Advanced DaemonSet。

• CloneSet：是面向無狀態(tài)應(yīng)用部署的工具，也是阿里巴巴中使用規(guī)模最大的部分，絕大部分泛電商業(yè)務(wù)都是通過 CloneSet 來部署發(fā)布，包括 UC 神馬、餓了么、電商業(yè)務(wù)等。

• Advanced StatefulSet：針對(duì)一個(gè)原生 StatefulSet 兼容的增強(qiáng)版本，是面向有狀態(tài)應(yīng)用部署的工具，目前主要是用于中間件在云原生環(huán)境的部署。

• SidecarSet：是在阿里巴巴環(huán)境中 sidecar 生命周期管理的工具。阿里巴巴的運(yùn)維容器，以及阿里內(nèi)部的 Mesh 容器，都是通過 SidecarSet 定義、部署以及注入到業(yè)務(wù) Pod 中的。

• Advanced DaemonSet：是針對(duì)原生 DaemonSet 兼容增強(qiáng)版本。將宿主機(jī)級(jí)別的守護(hù)進(jìn)程部署到所有節(jié)點(diǎn)上，包括各種用于給業(yè)務(wù)容器配置網(wǎng)絡(luò)、存儲(chǔ)的基礎(chǔ)組件。

介紹完基礎(chǔ)環(huán)境之后，我們已經(jīng)對(duì)云原生部署結(jié)構(gòu)有了一個(gè)基本的了解。下面，我們來了解在云原生部署結(jié)構(gòu)之下存在哪些云原生應(yīng)用安全危機(jī)。

3. 云原生應(yīng)用安全危機(jī)

1）workload 級(jí)聯(lián)刪除

Workload 級(jí)聯(lián)刪除，這一點(diǎn)不只針對(duì)于 Kruise 的 CloneSet，對(duì)于 Deployment，對(duì)于原生的 StatefulSet 都存在類似的問題。指的是當(dāng)我們刪除一個(gè) Workload 之后，假設(shè)使用采用默認(rèn)刪除，沒有使用 orphan 刪除這種策略的話，底下的 Pod 都會(huì)被刪掉，這里存在一種誤刪風(fēng)險(xiǎn)。也就是說，一旦某個(gè) Deployment 被誤刪，那么它底下的所有 Pod 都會(huì)級(jí)聯(lián)被刪掉，導(dǎo)致整個(gè)應(yīng)用不可用。如果有多個(gè) Workload 被刪掉，就可能導(dǎo)致很多個(gè)業(yè)務(wù)出現(xiàn)不可用的情況，這是一個(gè)對(duì)可用性造成的風(fēng)險(xiǎn)。如下圖所示：

2）namespace 級(jí)聯(lián)刪除

那么我們?cè)偻峡?#xff0c;如果 Namespace 被刪掉，那么整個(gè) Namespace 底下的所有資源，包括 Deployment、CloneSet 這些 Workload，也包括 Pod、Service 等所有資源都會(huì)被刪除，這是一種很高的誤刪風(fēng)險(xiǎn)。

3）CRD 級(jí)聯(lián)刪除

如果有用 Helm 部署的同學(xué)可能會(huì)遇到過類似的情況，也就是如果你的 Helm 中包含了一些 CRD，這些 CRD 都被定義在 template 中， 那么當(dāng) Helm uninstall 的時(shí)候，基本上這些 CRD 都會(huì)被 Helm 包級(jí)聯(lián)刪除掉，包括有人手動(dòng)誤刪了某個(gè) CRD，那么 CRD 底下對(duì)應(yīng)的 CR 都會(huì)被清理。這是一個(gè)很高的風(fēng)險(xiǎn)。

如果 CRD 是 CloneSet 這種 Workload 級(jí)別的 CRD，那么一旦刪除這個(gè) CRD 之后，會(huì)導(dǎo)致所有 CRD 底下的 CloneSet 的 CR 對(duì)象全部被刪掉，從而導(dǎo)致所有的業(yè)務(wù) Pod 全部被刪掉。也就是說，刪除一個(gè) Workload，只是這個(gè) Workload 底下的 Pod 被刪掉；刪除一個(gè) Namespace 可能只是 Namespace 底下的 Pod 被刪掉。但如果像阿里巴巴這種場(chǎng)景下，如果有人把 CloneSet 或者一些很關(guān)鍵的 CRD 刪掉的話 ，其實(shí)很可能導(dǎo)致整個(gè)集群環(huán)境所有 NameSpace 底下的 Pod 都會(huì)被級(jí)聯(lián)刪掉，或者說都會(huì)處于應(yīng)用不可用的狀態(tài)，造成云原生環(huán)境對(duì)于應(yīng)用可用性的風(fēng)險(xiǎn)。如下圖所示：

從上文可以看出來，云原生這種理念架構(gòu)為我們帶來的好處是面向終態(tài)，也就是說我們定義終態(tài)，從而整個(gè) Kubernetes 集群就會(huì)向終態(tài)靠攏。而一旦出現(xiàn)一些誤操作導(dǎo)致定義了一種錯(cuò)誤的終態(tài)，那么 Kubernetes 也會(huì)向錯(cuò)誤的終態(tài)靠攏，導(dǎo)致出現(xiàn)錯(cuò)誤的結(jié)果，從而影響到整個(gè)應(yīng)用的可用性。因此我們說，面向終態(tài)是一把“雙刃劍”。

4）并發(fā) Pod 更新/驅(qū)逐/刪除

除了幾種誤刪的情況，還有更多針對(duì)可用性的風(fēng)險(xiǎn)。如下圖所示，假設(shè)左邊 CloneSetA 部署了兩個(gè) Pod，這兩個(gè) Pod 中又被 SidecarSet 注入了對(duì)應(yīng)的 sidecar 容器。在這種情況下，如果通過 CloneSet 做應(yīng)用發(fā)布，假設(shè)說我們?cè)O(shè)置的 Max Available 是 50%，也就是說，兩個(gè) Pod 是逐個(gè)升級(jí)，前一個(gè)升級(jí)完成，后一個(gè)才能開始升級(jí)，默認(rèn)情況下這種發(fā)布策略是沒有問題的。

但是如果 Pod 有多個(gè) Owner，比如 CloneSet 是其中一個(gè) Owner，CloneSet 對(duì)上面的 Pod 開始做原地升級(jí)，SidecarSet 對(duì)第二個(gè) Pod 做 sidecar 的原地升級(jí)，那么同一時(shí)刻可能這個(gè)應(yīng)用的兩個(gè) Pod 都在被升級(jí)。因?yàn)樵?CloneSet 定義了 Max Unavailable 是 50%，從它的視角來看，只要選取兩個(gè) Pod 中的一個(gè)開始做升級(jí)。CloneSet 本身是無法感知到其它控制器甚至其他人為的行為去對(duì)其它 Pod 做操作，缺乏全局視角，每一個(gè)控制器都認(rèn)為自己在升級(jí)的 Pod 是符合升級(jí)策略，符合最大不可用測(cè)略。但當(dāng)多個(gè)控制器同時(shí)開始工作的時(shí)候，可能會(huì)導(dǎo)致整個(gè)應(yīng)用 100% 不可用。

如上圖右邊的情況，CloneSetC 底下有 3 個(gè) Pod，如果它開始做升級(jí)的時(shí)候只升級(jí)其中一個(gè) Pod，假設(shè)是重建升級(jí)，它會(huì)把舊版本 Pod 刪掉，先建新版本 Pod。在這過程中，假設(shè)另外兩個(gè) Pod 一個(gè)可能被 Kubelet，或者 kube-controller-manager 中的 node lifecycle controller 驅(qū)逐，這時(shí)候已經(jīng)有兩個(gè) Pod 不可用，已經(jīng)超過 Workload 中定義的最大不可用發(fā)布策略。在這個(gè)過程中，還可能有一些 Pod 被其他一些控制器其他有人工手動(dòng)刪除。種種可能性導(dǎo)致一個(gè) Workload 下 Pod 的不可用數(shù)量，很可能是超過本身 workload 中定義的不可用發(fā)布策略的。

也就是說，在 Deployment 中定義了 Max Unavailable 是 25%，那么 Deployment 在發(fā)布的時(shí)候，從它自身角度來看保證 25% 的 Pod 在被發(fā)布。其他 75% 的 Pod 并不保證完全可用，這 75% 的 Pod 可能被 Kubelet 驅(qū)逐、可能被人為手動(dòng)刪除、可能被 SidecarSet 外部熱升級(jí)等等，種種情況可能會(huì)導(dǎo)致 Deployment 超過 50% 不可用，甚至更高，使整個(gè)應(yīng)用受到影響。

云原生應(yīng)用安全防護(hù)實(shí)踐

針對(duì)以上種種危機(jī)，我們能采取怎么樣的措施，保證原生環(huán)境下應(yīng)用安全的可用性、安全性。下面介紹一些實(shí)踐的經(jīng)驗(yàn)。

1. 防護(hù)實(shí)踐 - 防級(jí)聯(lián)刪除

由于級(jí)聯(lián)刪除對(duì)應(yīng)用可用性危害非常大，包括了刪除 CRD 節(jié)點(diǎn)，刪除 Namespace 節(jié)點(diǎn)，以及刪除 Workload 節(jié)點(diǎn)。防級(jí)聯(lián)刪除定義了針對(duì)多種資源，包括 CRD、Namespace、包括原生 Deployment 在內(nèi)的各種 Workload 等，對(duì)這些資源提供了針對(duì)的 labels 定義。

下面是針對(duì)各種重要節(jié)點(diǎn)防級(jí)聯(lián)刪除的語(yǔ)名：

apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata:labels:policy.kruise.io/disable-cascading-deletion: true---apiVersion: v1 kind: Namespace metadata:labels:policy.kruise.io/disable-cascading-deletion: true---apiVersion: apps/v1 kind: Deployment metadata:labels:policy.kruise.io/disable-cascading-deletion: true---apiVersion: apps.kruise.io/v1alpha1 kind: CloneSet metadata:labels:policy.kruise.io/disable-cascading-deletion: true

labels 定義是關(guān)閉級(jí)聯(lián)刪除，用戶的任何 CRD、Namespace、workload 里帶有防級(jí)聯(lián)刪除標(biāo)識(shí)之后，kruise 就會(huì)保證資源防級(jí)聯(lián)刪除校驗(yàn)。也就是說，當(dāng)用戶刪除一個(gè) CRD 時(shí)，如果這個(gè) CRD 里帶有防級(jí)聯(lián)刪除這個(gè) label，那么 kruise 就會(huì)去查看 CRD 底下是否還有存量 CR，如果有存量 CR 那么 kruise 會(huì)禁止 CRD 刪除。

同理，在 Namespace 刪除時(shí)，也會(huì)校驗(yàn) Namespace 底下是否還有存量的運(yùn)行狀態(tài)的 Pod，如果有，會(huì)禁止用戶直接刪除 Namespace。

對(duì)于 workload 邏輯相對(duì)簡(jiǎn)單，就對(duì)于 Deployment、CloneSet、SidecarSet，當(dāng)用戶去刪除 workload 時(shí)，如果 workload 中用戶已經(jīng)定義了防級(jí)聯(lián)刪除的 label，那么 kruise 會(huì)檢查 workload 的 replica 是否為 0，如果 replica 大于 0，那么 kruise 是禁止用戶直接刪除帶有防級(jí)聯(lián)刪除標(biāo)識(shí)的 workload。也就是說，當(dāng)一個(gè)存量 Deployment，如果 replicas 大于 0 的情況下，如果 Deployment 中存在帶有防級(jí)聯(lián)刪除標(biāo)識(shí)，kruise 禁止用戶直接刪除。

如果真的需要?jiǎng)h除 Deployment 有兩種辦法：

• 第一，先把 replica 調(diào)為 “0”，這時(shí)底下 Pod 開始被刪除，這時(shí)刪除 Deployment 是沒問題的。

• 第二，可以把 Deployment 中防級(jí)聯(lián)刪除標(biāo)識(shí)去掉。

以上是關(guān)于防級(jí)聯(lián)刪除的介紹，大家應(yīng)該將防級(jí)聯(lián)刪除理解成安全防護(hù)最基礎(chǔ)的一個(gè)策略，因?yàn)榧?jí)聯(lián)刪除是 Kubernetes 中非常危險(xiǎn)的一個(gè)面向終態(tài)的能力。

2. 防護(hù)實(shí)踐 – Pod 刪除流控 & 熔斷

針對(duì) Pod 刪除流控 & 熔斷的策略，指的是用戶調(diào)用、或用控制器用 K8s 去做 Pod 驅(qū)逐時(shí)，一旦出現(xiàn)誤操作或者出現(xiàn)邏輯異常，很可能導(dǎo)致在整個(gè) K8s 集群范圍內(nèi)出現(xiàn) Pod 大規(guī)模刪除的情況。針對(duì)這種情況做了 Pod 刪除留空策略，或者說是一個(gè) CRD。這個(gè) CRD 用戶可以定義在一個(gè)集群中，不同的時(shí)間窗口內(nèi)，最多有多少 Pod 允許被刪除。

apiVersion: policy.kruise.io/v1alpha1 kind: PodDeletionFlowControl metadata:# ... spec:limitRules:- interval: 10mlimit: 100- interval: 1hlimit: 500- interval: 24hlimit: 5000whiteListSelector:matchExpressions:- key: xxxoperator: Invalue: foo

如上面這個(gè)例子，10 分鐘之內(nèi)最多允許 100 個(gè) Pod 被刪除，1 小時(shí)之內(nèi)最多允許 500 個(gè) Pod 被刪除，24 小時(shí)內(nèi)最多允許 5000 個(gè) Pod 被刪除。當(dāng)然也可以定義一些白名單，比如有些測(cè)試應(yīng)用，每天頻繁地巡檢、測(cè)試，頻繁刪除會(huì)影響整個(gè)流控，可以提供一個(gè)白名單，符合白名單的應(yīng)用不計(jì)算在窗口內(nèi)。

除了白名單之外，可能 90% 的常規(guī)應(yīng)用或者核心應(yīng)用，是受到刪除流控保護(hù)的。一旦存在規(guī)模性誤刪除操作，就會(huì)被刪除流控以及熔斷機(jī)制保護(hù)。包括在保護(hù)之后或者觸發(fā)閾值之后，最好提供這種報(bào)警機(jī)制、監(jiān)控機(jī)制，讓集群的管理者能快速的感知到線上出現(xiàn)的熔斷事件。還包括幫助管理者去判斷熔斷事件是一個(gè)正常的事件，還是一個(gè)異常的事件。

如果在這段時(shí)間內(nèi)，需要存在很多刪除請(qǐng)求，可以把對(duì)應(yīng)策略值相應(yīng)放大。如果真的是一些誤刪除，攔截到之后，及時(shí)根據(jù)請(qǐng)求來源做溯源，及時(shí)在搜索層面做熔斷，拒絕這些請(qǐng)求。

3. 防護(hù)實(shí)踐 - 應(yīng)用維度不可用數(shù)量保護(hù)

對(duì)應(yīng)用維度不可用數(shù)量保護(hù)，對(duì)于 K8s 原生，原生的 Kubernetes 提供了 PDB(PodDisruptionBudge) 策略，但是 PDB 只能攔截 Pod eviction 驅(qū)逐操作，也就是 Pod 驅(qū)逐操作。

apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata:name: xxx spec:minAvailable: 2selector:matchLabels:app: xxx

上面的這個(gè)例子，假設(shè)其中有 5 個(gè) Pod，這時(shí)定義了 minAvailable=2，就保證最少有 2 個(gè) Pod 處于可用。一旦有 3 個(gè) Pod 不可用，還剩下 2 個(gè) Pod 可用，這時(shí)候如果 Pod eviction 針對(duì)存量 2 個(gè) Pod 做驅(qū)逐，這個(gè)時(shí)候 PDB 會(huì)保護(hù) Pod 可用性，拒絕這次驅(qū)逐操作。但是相應(yīng)的如果對(duì)存量 2 個(gè) Pod 做刪除或者原地升級(jí)，或者去做其他導(dǎo)致 Pod 不可用的事情，PDB 是沒有辦法攔截，尤其是針對(duì) Pod 刪除請(qǐng)求，比 Pod 驅(qū)逐更為常見，但是 PDB 是沒辦法攔截刪除等請(qǐng)求。

對(duì)于這些問題，阿里巴巴做了 PodUnavailableBudget 攔截操作，也就是 PUB。這里的 Unavailable 能做的操作就更多了，基本上所有可能導(dǎo)致 Pod 不可用的操作，都在 PodUnavailableBudget 保護(hù)范圍內(nèi)，包括了驅(qū)逐請(qǐng)求、Pod 刪除請(qǐng)求，應(yīng)用原地升級(jí)、Sidecar 原地升級(jí)、容器重啟等，所有導(dǎo)致應(yīng)用不可用的操作都會(huì)被 PUB 攔截。

如下面這個(gè)例子：

apiVersion: policy.kruise.io/v1alpha1 kind: PodUnavailableBudget spec:#selector:# app: xxxtargetRef:apiVersion: apps.kruise.iokind: CloneSetname: app-xxxmaxUnavailable: 25%# minAvailable: 15 status:deletedPods:pod-uid-xxx: "116894821"unavailablePods:pod-name-xxx: "116893007"unavailableAllowed: 2currentAvailable: 17desiredAvailable: 15totalReplicas: 20

定義了一個(gè) PUB，這個(gè) PUB 可以像原生 PDB 一樣寫一個(gè) selector 范圍，也可以通過 targetRef 直接關(guān)聯(lián)到某一個(gè) Workload，保護(hù)范圍就是在 Workload 底下的所有 Pod，同樣也可以定義最大不可用數(shù)量，以及最小可用數(shù)量。

假設(shè)對(duì)于 CloneSet 底下總共 20 個(gè) Pod，當(dāng)定義了 maxUnavailable：25% 時(shí)，一定要保證至少有 15 個(gè) Pod 處于可用狀態(tài)。也就是說，PUB 會(huì)保證這 20 個(gè) Pod 中最多有 5 個(gè)處于不可用狀態(tài)。回到我們之前在“危機(jī)”部分講到的一個(gè)例子，如果這 20 個(gè) Pod 同時(shí)在被 Cloneset 發(fā)布，以及被 Kubelet 驅(qū)逐，或是人工手動(dòng)刪除，一旦 Pod 不可用數(shù)量超過 5 個(gè)，不管是 Kubelet 對(duì)剩余 15 個(gè) Pod 做驅(qū)逐，還是人為手動(dòng)刪除剩余的某些 Pod，這些操作都會(huì)被 PUB 所攔截，這種策略能完全保證應(yīng)用在部署過程中的可用性。PUB 可以保護(hù)的范圍比 PDB 大很多，包括在實(shí)際使用過程中預(yù)期之外的一些刪除請(qǐng)求、升級(jí)請(qǐng)求，從而保證整個(gè)應(yīng)用在運(yùn)行時(shí)的穩(wěn)定性和可用性。

4. 防護(hù)實(shí)踐 - PUB/PDB 自動(dòng)生成

對(duì)于真正的 Depoyment 應(yīng)用開發(fā)者、運(yùn)維人員來說，一般而言，只需要定義自身 workload 中 template，業(yè)務(wù)方只關(guān)心 Depoyment templatek 中業(yè)務(wù)的版本、環(huán)境變量、端口、提供的服務(wù)，但我們很難去強(qiáng)制每一個(gè)業(yè)務(wù)方在定義應(yīng)用時(shí)，另外寫一個(gè) PUB 或者 PDB 保護(hù)策略的 CR。那么，我們?cè)鯓訉?duì)每一個(gè)應(yīng)用提供自動(dòng)保護(hù)呢？

在阿里巴巴內(nèi)部，我們針對(duì)每個(gè) Workload 提供自動(dòng)生成 PUB/PDB 的能力。比如說，如果用戶此時(shí)新創(chuàng)建了一個(gè) Deployment，會(huì)通過控制器自動(dòng)為該 Deployment 生成一個(gè)匹配的 PUB。這個(gè)自動(dòng)生成的功能即能支持原生 Deployment/StatefulSet，也支持 Kruise 的 CloneSet / Advanced StatefulSet / UnitedDeployment。第二，默認(rèn)根據(jù) strategy 中 maxUnavailable 策略。第三，允許 annotation 中單獨(dú)定義保護(hù)策略。如下面的語(yǔ)句所示：

apiVersion: apps kind: Deployment metadata:name: deploy-fooannotations:policy.kruise.io/generate-pub: "true"policy.kruise.io/generate-pub-maxUnavailable: "20%"# policy.kruise.io/generate-pub-minAvailable: "80%" spec:strategy:type: RollingUpdaterollingUpdate:maxUnavailable: 25%maxSurge: 25%# ...--- # auto generate: apiVersion: policy.kruise.io/v1alpha1 kind: PodUnavailableBudget spec:targetRef:apiVersion: appskind: Deploymentname: deploy-foomaxUnavailable: 20%

自動(dòng)生成的 PUB/PDB 內(nèi)部填寫的 maxUnavailable，既可以讓用戶在 kruise 中指定定義。比如用戶可以直接把 kruise.io/generate-pub:“true”，也可以 kruise.io/generate-pub-maxUnavailable:“20%”，可以讓用戶指定應(yīng)用最多允許有多少個(gè)不可用。這是用戶指定的策略。

如果用戶沒有指定策略，會(huì)根據(jù)在發(fā)布策略中存在的maxUnavailable生成 PUB。就是指在發(fā)布的階段，有多少個(gè)不可用數(shù)量，做為應(yīng)用運(yùn)行時(shí)最大不可能數(shù)量。這是允許單獨(dú)定義策略。

OpenKruise 的新領(lǐng)域

1. OpenKruise 介紹

最后，和大家介紹上述開放的能力在 OpenKruise 新領(lǐng)域如何去開放，以及怎么拓展對(duì) OpenKruise 的認(rèn)知。OpenKruise 是阿里云開源的 Kubernetes 擴(kuò)展應(yīng)用負(fù)載項(xiàng)目，本質(zhì)上是圍繞 Kubernetes 云原生應(yīng)用去做一系列自動(dòng)化能力的引擎，同時(shí)也是阿里巴巴經(jīng)濟(jì)體上云全面使用的部署基座。

OpenKruise 的定位，做的不是一個(gè)完整的平臺(tái)，更類似于是 Kubernetes 中一個(gè)拓展的產(chǎn)品。這個(gè)拓展的產(chǎn)品作為一個(gè) add on 的組件，提供了一系列針對(duì)在 Kubernetes 中部署應(yīng)用，以及后續(xù)保護(hù)防護(hù)應(yīng)用可用、圍繞云原生應(yīng)用的一些自動(dòng)化的能力，這些拓展能力或者增強(qiáng)能力，是原生 Kubernetes 所不具備，但也是迫切需要它所擁有這些能力，是阿里巴巴內(nèi)部在云原生逐漸演進(jìn)過程中去沉淀的一些通用能力。

目前，Kruise 提供了以下 workload 控制器：

• CloneSet：提供了更加高效、確定可控的應(yīng)用管理和部署能力，支持優(yōu)雅原地升級(jí)、指定刪除、發(fā)布順序可配置、并行/灰度發(fā)布等豐富的策略，可以滿足更多樣化的應(yīng)用場(chǎng)景。

• Advanced StatefulSet：基于原生 StatefulSet 之上的增強(qiáng)版本，默認(rèn)行為與原生完全一致，在此之外提供了原地升級(jí)、并行發(fā)布(最大不可用)、發(fā)布暫停等功能。

• SidecarSet：對(duì) sidecar 容器做統(tǒng)一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器。

• UnitedDeployment：通過多個(gè) subset workload 將應(yīng)用部署到多個(gè)可用區(qū)。

• BroadcastJob：配置一個(gè) job 在集群中所有滿足條件的 Node 上都跑一個(gè) Pod 任務(wù)。

• Advanced DaemonSet：基于原生 DaemonSet 之上的增強(qiáng)版本，默認(rèn)行為與原生一致，在此之外提供了灰度分批、按 Nodelabel 選擇、暫停、熱升級(jí)等發(fā)布策略。

• AdvancedCronJob：一個(gè)擴(kuò)展的 CronJob 控制器，目前 template 模板支持配置使用 Job 或 BroadcastJob。

2. 原生 workload 能力缺陷

根據(jù) Deployment 去 CloneSet、AdcancedStatefulSet 是因?yàn)樵?workload 能力缺陷有很多。大家可以看到，基本上從 Kubernetes 1.10 版本之后，其實(shí)其他的功能，包括 pod 里面，它的字段還是在不斷豐富，包括更多的 pod 的能力支持、更多的策略等，但是對(duì)于 workload 層面，就是 deployment 和 StatefulSet 層面，已經(jīng)不傾向于做任何改動(dòng)。社區(qū)在這背后的考慮是因?yàn)樵诓煌尽⒉煌瑯I(yè)務(wù)場(chǎng)景下，應(yīng)用部署發(fā)布層面需求很多。

Kubernetes 原生提供的 Deployment，是面向一些最通用最基礎(chǔ)的一些環(huán)境，沒辦法用它去滿足所有的業(yè)務(wù)場(chǎng)景，但實(shí)際上社區(qū)是非常鼓勵(lì)有更高需求，更大更復(fù)雜場(chǎng)景規(guī)模需求的用戶，自行通過 CRD 去拓展編寫，利用更強(qiáng)大的 workload，來滿足不同的業(yè)務(wù)的場(chǎng)景需求。

3. OpenKruise與原生能力對(duì)比

橙色：開源中 / 綠色：已開源

那么，對(duì)于這場(chǎng)景而言，Kruise 已經(jīng)做了比較完備的一個(gè)無狀態(tài)以及有狀態(tài)應(yīng)用的部署，通過上圖表格能看到 Kruise 提供的 workload 和原生 deployment、StatefulSet、DaemonSet 的對(duì)比。

4. OpenKruise 2021 規(guī)劃

如上圖所示，OpenKruise 是一個(gè)云原生應(yīng)用自動(dòng)化引擎，目前提供的 workload 能力在應(yīng)用部署，但不會(huì)僅局限于應(yīng)用部署這一個(gè)領(lǐng)域的。

1）風(fēng)險(xiǎn)防控

在 2021 年上半年的規(guī)劃中，我們會(huì)針對(duì)上面講到的云原生應(yīng)用的風(fēng)險(xiǎn)和防控的策略，會(huì)通過 OpenKruise 輸出給社區(qū)。包括 CRD 刪除防護(hù)、級(jí)聯(lián)刪除防護(hù)、全局 Pod 刪除流控、Pod 刪除/驅(qū)逐/原地升級(jí)防護(hù)、自動(dòng)為 workload 生成 PDB/PUB 等。

2）Kruise-daemo

除此之外之前 OpenKruise 只是作為一個(gè)中心的控制器部署，下個(gè)版本中會(huì)提供一個(gè) Kruise-daemon 通過 daemon set 部署到每個(gè)節(jié)點(diǎn)上，可以幫用戶去做一些鏡像預(yù)熱，發(fā)布加速，容器重啟 ，單機(jī)調(diào)度優(yōu)化的一些策略。

3）ControllerMesh

ControllerMesh 是 OpenKruise 提供出來幫助用戶管理用戶集群中其他運(yùn)行時(shí)的一些控制器運(yùn)行時(shí)的能力，通過流量控制等方式解決傳統(tǒng)控制器單住模式帶來的種種問題。

最后，在 OpenKruise 項(xiàng)目社區(qū)建設(shè)方面，已經(jīng)在 2020 年 11 月 11 號(hào)經(jīng) CNCF 技術(shù)監(jiān)督委員會(huì)全體成員投票，一致同意正式進(jìn)入 CNCF Sanbox，在整個(gè)過程中也得到了 CNCF 積極的回應(yīng)，表示 OpenKruise 項(xiàng)目與 CNCF 倡導(dǎo)的理念很契合，鼓勵(lì)有更多像 OpenKruise 這樣能做一些通用化的，面向更復(fù)雜的場(chǎng)景，更大規(guī)模的一些這種自主的 Workload 能力的項(xiàng)目出現(xiàn)。

現(xiàn)在已經(jīng)有很多公司在使用 OpenKruise 的這些能力，比如：

• 基于原地升級(jí)、灰度發(fā)布等需求，攜程在生產(chǎn)環(huán)境使用CloneSet、AdvancedStatefulSet 來分別管理無狀態(tài)、有狀態(tài)應(yīng)用的服務(wù)，單集群 Kruise workload 數(shù)量達(dá)到萬(wàn)級(jí)別。

• OPPO 公司不僅大規(guī)模使用了 OpenKruise，還在下游配合其定制化的 Kubernetes 進(jìn)一步加強(qiáng)了原地升級(jí)的能力，廣泛應(yīng)用在多個(gè)業(yè)務(wù)的后端運(yùn)行服務(wù)中，通過原地更新覆蓋了 87% 左右的升級(jí)部署需求。

• 此外，國(guó)內(nèi)的用戶還有蘇寧、斗魚 TV、有贊、比心、Boss 直聘、申通、小紅書、VIPKID、掌門教育、杭銀消費(fèi)、萬(wàn)翼 科技、多點(diǎn) Dmall、佐疆科技、享住智慧、艾佳生活、永輝科技中心、跟誰(shuí)學(xué)，國(guó)外的用戶有 Lyft、Bringg、 Arkane Systems 等。

• Maintainer 5 位成員來自阿里巴巴、騰訊、Lyft

• 51 位貢獻(xiàn)者

  • 國(guó)內(nèi)：阿里云、螞蟻集團(tuán)、攜程、騰訊、拼多多…

  • 國(guó)外：微軟、Lyft、Spectro Cloud、Dsicord…

• 2000+ GitHub Stars

• 300+ Forks

如果大家對(duì) OpenKruise 項(xiàng)目感興趣，有任何希望交流的話題，歡迎大家訪問 OpenKruise 官網(wǎng)、GitHub。

“Kubernetes 與云原生應(yīng)用開源實(shí)踐大講堂”

4 場(chǎng)云原生與 Kubernetes 技術(shù)前沿話題直播、70 節(jié)經(jīng)典課程、3 本云原生電子書，來“Kubernetes 與云原生應(yīng)用開源實(shí)踐大講堂”，和阿里云容器技術(shù)專家一起，將熱門的容器開源項(xiàng)目和前沿的云原生應(yīng)用落地實(shí)踐一網(wǎng)打盡！點(diǎn)擊直達(dá)“Kubernetes 與云原生應(yīng)用開源實(shí)踐大講堂”！

總結(jié)

以上是生活随笔為你收集整理的阿里巴巴云原生应用安全防护实践与 OpenKruise 的新领域的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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