作者｜趙明山（立衡）

前言

OpenKruise 是阿里云開(kāi)源的云原生應(yīng)用自動(dòng)化管理套件，也是當(dāng)前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 項(xiàng)目。它來(lái)自阿里巴巴多年來(lái)容器化、云原生的技術(shù)沉淀，是阿里內(nèi)部生產(chǎn)環(huán)境大規(guī)模應(yīng)用的基于 Kubernetes 之上的標(biāo)準(zhǔn)擴(kuò)展組件，也是緊貼上游社區(qū)標(biāo)準(zhǔn)、適應(yīng)互聯(lián)網(wǎng)規(guī)模化場(chǎng)景的技術(shù)理念與最佳實(shí)踐。
?
OpenKruise 在 2021.9.6 發(fā)布了最新的 v0.10.0 版本新增了彈性拓?fù)涔芾砗蛻?yīng)用安全防護(hù)等能力，本文將為大家揭曉 OpenKruise 是如何實(shí)現(xiàn)應(yīng)用的可用性防護(hù)能力。

背景

在文章開(kāi)始部分，我想先聊聊到底什么是“應(yīng)用的可用性防護(hù)”。例如，在 Kubernetes 上面部署的 ETCD 服務(wù)，時(shí)刻要保證可用的實(shí)例數(shù)不小于 N（受限于 raft 協(xié)議的選舉機(jī)制）。很多同學(xué)都會(huì)想到 Deployment 中可以設(shè)置 maxUnavailable，那不就行了嗎？再說(shuō)了，還會(huì)有 RS Controller 在做副本控制呢？仔細(xì)想想，Deployment 的 MaxUnavailable 是在應(yīng)用滾動(dòng)發(fā)布的過(guò)程中保證最小的 Pod 數(shù)量，而 RS Controller 控制器則是盡快讓?xiě)?yīng)用實(shí)際的福本數(shù)等于預(yù)期的副本數(shù)，并不能保證應(yīng)用每時(shí)每刻的最小可用副本數(shù)。

針對(duì)上述場(chǎng)景，Kubernetes 原生提供的 PodDisruptionBudget（PDB）通過(guò)限制同時(shí)中斷 Pod 的數(shù)量，來(lái)保證應(yīng)用的高可用性。但是，當(dāng)前 PDB 的能力并不全面，它只能防護(hù) Pod Eviction 場(chǎng)景（例如：kubectl drain node 驅(qū)逐 node 上面的 Pod）。在如下“并發(fā) Pod 更新/驅(qū)逐/刪除”場(chǎng)景中，即便有 PDB 防護(hù)依然將會(huì)導(dǎo)致業(yè)務(wù)中斷、服務(wù)降級(jí)：

• 應(yīng)用 owner 通過(guò) Deployment 正在進(jìn)行版本升級(jí)，與此同時(shí)集群管理員由于機(jī)器資源利用率過(guò)低正在進(jìn)行 node 縮容
• 中間件團(tuán)隊(duì)利用 SidecarSet 正在原地升級(jí)集群中的sidecar版本（例如：ServiceMesh envoy），同時(shí) HPA 正在對(duì)同一批應(yīng)用進(jìn)行縮容
• 應(yīng)用 owner 和中間件團(tuán)隊(duì)利用 CloneSet、SidecarSet 原地升級(jí)的能力，正在對(duì)同一批 Pod 進(jìn)行升級(jí)

PodUnavailableBudget 提升應(yīng)用的高可用性

Kubernetes 原生 PDB 為什么只能防護(hù) Pod Eviction 的場(chǎng)景呢？首先，讓我們來(lái)看看它的實(shí)現(xiàn)原理：PDB 通過(guò) selector 選擇了一批防護(hù)的 Pod 列表，minAvailable 則表明最小可用的 Pod 數(shù)量，pdb-controller 根據(jù)前面兩個(gè)值以及線上 Pod 的 ready 狀態(tài)，計(jì)算出當(dāng)前時(shí)刻最多允許中斷的 Pod 數(shù)量 PodDisruptionAllowd。k8s pod evictionRestful API 接口則會(huì)根據(jù) pdb PodDisruptionAllowd 來(lái)決定接口成功還是返回 400 報(bào)錯(cuò)。到了這里終于真相大白了，pdb 通過(guò) evictionRestful API 接口來(lái)實(shí)現(xiàn) pod 的防護(hù)能力，所以它只能適用于 Pod Eviction 場(chǎng)景。

OpenKruise PodUnavailableBudget（PUB）安全防護(hù)的整體思路與 PDB 其實(shí)也大致相同，不過(guò)在關(guān)鍵的防護(hù)路徑上面做了一些調(diào)整。Voluntary Disruption（諸如：集群管理員驅(qū)逐 Node、并發(fā)升級(jí) Pod）主動(dòng)導(dǎo)致 Pod 不可用的場(chǎng)景其實(shí)可以歸納為以下三類(lèi)：

• Modification Pod.Spec 定義（CloneSet、SidecarSet 原地升級(jí) container）
• Delete Pod（Deployment 等控制器滾動(dòng)升級(jí) Pod、直接 Delete Pod）
• Eviction API（kubectl drain node 驅(qū)逐 Pod）

OpenKruise 基于 Kubernetes Adminssion Webhook 機(jī)制添加針對(duì) Pod Update/Delete/Eviction 的 webhook 邏輯，根據(jù) pub 的 PodUnavailableAllowed 來(lái)實(shí)現(xiàn)更加全面的應(yīng)用 Pod 安全防護(hù)機(jī)制，邏輯架構(gòu)如下：

應(yīng)用場(chǎng)景

• 無(wú)狀態(tài)應(yīng)用：比如想至少有 60% 的副本 Available
• • 解決辦法：創(chuàng)建 PUB Object，指定 minAvailable 為 60%，或者 maxUnavailable 為 40%

apiVersion: apps.kruise.io/v1alpha1 kind: PodUnavailableBudget metadata:name: web-server-pubnamespace: web spec:targetRef:apiVersion: apps.kruise.io/v1alpha1kind: CloneSetname: web-serverminAvailable: 60%

• 有狀態(tài)應(yīng)用：最少可用的實(shí)例數(shù)不能少于某個(gè)數(shù) N（比如受限于 raft 協(xié)議類(lèi)應(yīng)用的選舉機(jī)制）
• • 解決辦法：設(shè)置 maxUnavailable=1 或者 minAvailable=N，分別允許每次只刪除一個(gè)實(shí)例或每次刪除 workload.replicas - minAvailable 個(gè)實(shí)例

apiVersion: apps.kruise.io/v1alpha1 kind: PodUnavailableBudget metadata:name: etcd-pubnamespace: etcd spec:targetRef:apiVersion: apps.kruise.io/v1alpha1kind: StatefulSetname: etcdmaxUnavailable: 1

• 單實(shí)例應(yīng)用：終止這個(gè)實(shí)例之前必須提前通知客戶并取得同意
• • 解決辦法：創(chuàng)建 PUB Object，并設(shè)置 maxUnavailable 為 0，這樣 OpenKruise 就會(huì)阻止這個(gè)實(shí)例的刪除，然后去通知并征求用戶同意后，再把這個(gè) PUB 刪除從而解除這個(gè)阻止，然后再去 recreate

apiVersion: apps.kruise.io/v1alpha1 kind: PodUnavailableBudget metadata:name: gameserver-pubnamespace: game spec:targetRef:apiVersion: apps.kruise.io/v1alpha1kind: StatefulSetname: gameservermaxUnavailable: 0

總結(jié)

Kubernetes 給用戶帶來(lái)極致彈性調(diào)度的同時(shí)也給應(yīng)用的高可用性帶來(lái)了一定的考驗(yàn)，PUB 是在 Voluntary Disruption 場(chǎng)景下的一種嘗試，同時(shí)配合 OpenKruise 提供的防級(jí)聯(lián)刪除的能力相信能在一定程度上提升線上應(yīng)用的穩(wěn)定性。而針對(duì)更加棘手 InVoluntary Disruption（諸如：集群 Node 網(wǎng)絡(luò)腦裂、vk 節(jié)點(diǎn)異常）導(dǎo)致 Pod 不可用等降低應(yīng)用可用性的場(chǎng)景，OpenKruise 未來(lái)也會(huì)有更多的探索。與此同時(shí)，我們也歡迎更多的同學(xué)參與到 OpenKruise 社區(qū)來(lái)，共同建設(shè)一個(gè)場(chǎng)景更加豐富、完善的 K8s 應(yīng)用管理、交付擴(kuò)展能力，能夠面向更加規(guī)模化、復(fù)雜化、極致性能的場(chǎng)景。

Github：https://github.com/openkruise/kruise
Official：https://openkruise.io/
Slack: Channel in Kubernetes Slack
釘釘交流群：搜索群號(hào)【23330762】可添加~

戳鏈接（https://github.com/openkruise/kruise），查看 OpenKruise 項(xiàng)目 github 主頁(yè)！！

總結(jié)

以上是生活随笔為你收集整理的OpenKruise 如何实现应用的可用性防护？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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