背景

隨著 Kubernetes 在企業中大規模使用和落地，逐漸形成了 "業務 - 中臺 - 基礎設施" 的分層技術體系；這種分層能夠屏蔽平臺和基礎設施層的復雜概念，讓應用專注于業務層的研發，但同時也會導致上層應用的穩定性強依賴底層基礎設施的支持，從而對基礎設施在大規模集群下的穩定性提出極大的挑戰：

• 由于集群規模龐大，任何單一不起眼的小問題都可能被無限放大，帶來系統性風險；
• 場景的復雜性和多樣性，也使得運維操作出現不符合預期的行為難以徹底避免。

這就要求我們對于 Kubernetes 所管理的資源和對象進行更有效的極端風險防護，盡可能緩解由于誤操作、組件版本與配置的錯誤、或者管控代碼 bug 對業務造成不可挽回的影響。

盡管 Kubernetes 原生提供了一系列的防護機制，例如嚴格的 RBAC 校驗機制、使用 PodDisruptionBudget（PDB）對 Eviction API 執行校驗、較為豐富的 Admission Plugins 等，但是在實際生產實踐中，我們仍然發現有很多無法覆蓋的場景。

在此背景下，字節跳動內部對 Kubernetes 系統進行了擴展與改造，增加了一系列的防御性校驗措施與操作約束，為運行在 Kubernetes 上的業務提供更強有力的穩定性支撐，降低極端風險。

防護加固

Kubernetes 是個相當復雜的分布式系統，但其架構設計上的核心思想還是非常簡單的。Kubernetes 通過 APIServer 提供統一的 API 接口實現對集群狀態的訪問與修改能力；各種自動化組件能以標準化的方式與集群通信持續獲取數據，并通過本地計算當前集群狀態與預期集群狀態之間的區別，派生出一系列的變更操作；最終通過 kubelet 在每個節點上執行這些狀態變更，將集群朝著預期的狀態推進。

由此可見，Kubernetes 組件間的交互和運行狀態可以大致分成以下三層

• KV 存儲系統（如 etcd、Kine、Kubebrain）與 apiserver 間的交互，提供 key-value 級別的讀寫操作與事件監聽；
• apiserver 與各種內建或附加 controller/operator 間（以及 apiserver 與用戶間）通過 API 請求交互；
• apiserver 與單機節點組件間的交互。

根據上述分層，我們可以針對性梳理出一系列常見的系統性風險，并分別采取對應的措施進行加固以降低極端風險。

數據防護

存儲與 apiserver 之間的交互風險主要集中數據異常方面，例如數據的損壞與丟失等；存儲系統是 Kubernetes 的核心，是整個基于事件驅動的分布式系統的基石，一旦出現數據異常可能直接或間接地派生出一系列的故障。具體來說可能包括但不限于以下的常見極端風險問題：

• 存儲集群運維操作失誤導致存儲下線，導致整個 Kubernetes 集群不可用；
• 管理員直接刪除 etcd 中的數據，未經過 apiserver 做校驗，可能導致一些非預期關鍵對象如 namespace、deployment、pod 等被直接刪除，并觸發對象的級聯刪除，導致業務大面積受損；
• 管理員因誤操作直接修改 etcd 中的數據，損壞了數據格式導致 apiserver 無法 decode 數據。

針對這些問題，我們在生產環境中采取了一系列措施——首先，盡可能標準化地約束對存儲集群的運維和數據操作，在存儲系統側開啟 TLS 雙向認證，盡量避免除了 Kubernetes 以外的用戶直接訪問存儲，降低數據損壞或丟失的風險；其次，對存儲進行定時的備份，在極端情況下，當發生不可逆的數據損失時，基于備份能快速恢復數據，降低損失的影響；此外，通過對其他組件進行加固，盡可能降低數據異常派生的非預期事件對于業務的直接沖擊。

控制面防護

自動化組件與 apiserver 之間的交互風險，主要集中在非預期操作方面。正常情況下，用戶或平臺將預期的狀態提交到 apiserver，而其他內部組件將立即根據當前狀態和預期狀態的區別派生出一系列的動作，從而使集群產生變更；而一旦錯誤的預期狀態被提交，集群將快速并且難以逆轉地朝著目標狀態進行變更。

針對這一類問題的主要防護思路，就是對關鍵對象的操作進行一些額外的限制，例如要求在操作時額外添加一些冗余操作，形成 double check 機制，降低由于誤操作或者管控代碼 bug 引發風險的概率；具體來說，操作防護通過 Kubernetes 原生提供的擴展機制 ValidatingAdmissionWebhook 來實現。我們通過 label 和 annotation 來標記需要進行操作防護的關鍵對象，并通過 selector 配置對這些關鍵對象以及對應的操作進行篩選，在 Webhook 中實現一系列的約束以達到防護的目的，其中包括但不限于以下這些策略：

• 防止級聯刪除針對 Namespace、CRD 等根對象，一旦被刪除會導致級聯地觸發派生出的其他對象的刪除操作。因此我們在 Webhook 中對這些類型的關鍵對象的刪除進行攔截，避免誤操作引發級聯刪除操作引發災難性后果。
• 顯式副本修改當需要調整關鍵 workload 資源副本數量時，為了避免意外地將副本數量縮減至 0，我們要求在通過 UPDATE 或者 PATCH 請求調整副本數的同時，還需要顯式地給對象添加特定 annotation 寫入預期調整的數值作為 double check；在 Webhook 中校驗關鍵 workload 對象進行變更時 .spec.replicas 字段中的值是否與 annotation 中提供的值保持一致，確保任何對于關鍵 workload 副本數的修改都是有意且明確的。
• 顯式資源刪除當需要刪除關鍵 workload 對象時，要求在刪除對象之前先通過修改操作將 workload 的副本數降至 0；通過這種約束，我們得以避免一些誤操作，例如某些關鍵的 workload 對象未經確認直接，可能會觸發更多級聯的刪除操作，導致業務受損。
• 操作程序約束對于一些特定的業務，對于業務規格的變更有著嚴格的變更事件窗口限制，例如業務只接受在非繁忙時段對鏡像、環境變量等配置進行變更，這樣可以降低因為規格更改引起的潛在問題，以及相應的業務中斷風險。我們通過 CRD 定義了可變更窗口、可變更字段等約束并暴露給用戶，在 Webhook 中根據用戶配置進行相應的校驗，這樣可以確保在出現故障時，影響盡量少的終端用戶，確保有相對充分的故障處理時間，最大程度的減少潛在損失，降低系統風險。

此外，線上生產環境中經常會遇到一些客戶端的異常，例如 OOM、大量緩存穿透等問題，這些異常往往會引發大量的開銷極大的讀請求，引發控制面異常甚至雪崩。針對線上異常流量的防護問題，我們對用戶行為進行了一定限制，禁止了一些開銷極大的讀穿透行為。其次，我們在控制面前置了針對 kube-apiserver 流量特征專門定制的七層網關 KubeGateway，它解決了 kube-apiserver 負載不均衡的問題，同時實現了對 kube-apiserver 請求的完整治理，包括請求路由、分流、限流、降級等，顯著提高了 Kubernetes 集群的可用性。另外，我們對 Kubernetes 的審計日志進行擴展，將一些流量相關的信息附加到審計日志上，在此基礎上進行分析得到用戶畫像。在異常的場景下，將用戶畫像、流量監控指標與控制面前置的七層網關 KubeGateway 的限流能力相結合，對給控制面提供巨大壓力的 Client 進行流量控制，盡可能降低雪崩風險。

節點防護

在大多數場景下，pod 的刪除應該分成兩個階段執行：首先由中心化的 Controller 或者用戶通過發起 Delete 請求將 pod 標記為刪除狀態（即添加 DeletionTimestamp），然后應該由 kubelet 負責對業務發起優雅退出，等待業務終止且資源釋放之后，由 kubelet 來通過 APIServer 提供的接口將 pod 徹底移除。但在生產實踐中，我們遇到諸多了問題，可能導致 kubelet 因為異常而非預期地終止業務 pod，例如：

• 由于配置錯誤或者代碼 bug，導致 kubelet 重啟后 reject 正在運行的業務 pod，導致業務受損；
• 由于控制面存儲出現的數據損壞或其他異常，導致 kubelet 發現本地實際運行的 pod 與控制面提供的本地應該運行的 pod 不一致，進而引起非預期的業務退出。

針對這類問題，我們對 kubelet 進行了一系列的改造，涵蓋 admit、housekeeping 等環節。通過改造給 kubelet 刪除 pod 的操作加入前置約束：在嘗試刪除關鍵 pod 時，首先檢查 pod 是否被顯式地進行標記刪除，如果 pod 未被標記刪除，則不允許 kubelet 觸發 pod 的刪除操作。基于這種顯式刪除的約束，我們得以大幅度降低因為各種 Kubernetes 組件異常而引發的節點層面的業務運行風險。

小結

在生產環境中，我們主要根據 Kubernetes 組件之間的交互過程識別和梳理出關鍵風險，通過特定的 label 與 annotation 對關鍵的對象進行標記，分別采取措施進行一定的加固：

• 數據防護主要是約束運維操作，收斂數據訪問入口，標準化存儲操作的各種行為以減小風險；
• 控制面防護主要是通過定制 ValidatingAdmissionWebhook 進行擴展，在對于一些關鍵對象的變更過程中，要求主動引入一些冗余的操作與校驗，降低誤操作風險；
• 節點防護主要是通過對 kubelet 的進行改造，嚴格約束關鍵 pod 必須顯式刪除，降低極端情況下的系統性風險。

應用案例

字節基于原生 Kubernetes 生態定制了較多的功能以支持個性化的場景，整體的研發、迭代和交付的效率都非常高，對集群穩定性造成更大的挑戰，即使在交付流程規范上嚴格把控，也不能完全杜絕異常情況下的極端異常風險；結合實踐過程出現過的故障案例和場景訴求，字節云原生團隊從元集群、控制面、數據面、業務定制等多個角度，構建了較為全面的防御體系，有效避免線上大規模事故的發生。

數據防護：元集群級聯刪除

字節內部的集群數量眾多，為實現自動化運維和集群管理，需要構建元集群描述業務集群的狀態；在這種情況下，元集群自身的異常可能會觸發更大范圍的故障。在字節早期，集群缺乏防護能力，SRE 在運維過程中使用過高權限，誤刪除了某個 region 元集群中用于描述 Node 狀態的 CRD，因為沒有防御系統攔截，CRD 被刪除后會引發全量 CR 的級聯刪除，導致元集群控制器認為幾乎所有的節點都需要下線，引發全量 pod 物理停服。該次故障最終引發單 region 生產集群在 30 分鐘內持續標記刪 3W+ 節點，實際刪除 9K 節點后及時止損，影響面巨大且手動止損窗口很短。在該案例中，接入防御體系能夠實現在多個點位實現防御能力

• 前置攔截：通過標記 CRD 為 critial 避免全量誤刪除引發級聯問題；
• 集群下線限流：集群大范圍下線通常并不是常見的運維操作，控制節點下線的頻率和安全水位，保證即使出現異常的級聯刪除行為，也能夠盡量控制故障域；
• 數據備份和恢復：當發生物理對象刪除行為后，能夠通過備份數據實現快速的恢復。

控制面防護：異常流量識別與限流

控制面異常通常源自于不合理的客戶端行為和不夠準確的服務端資源預估，由于場景過于復雜，在缺乏精細治理的情況下，最終因各種原因導致服務端過載；通常從現象上，會伴隨著客戶端大量的 List 請求和 APIServer OOM，進一步引發全量客戶端 Relist，惡性循環直至集群出現雪崩。對于控制面的極端異常，字節內部通過接入 7 層的 gateway ，配合全鏈路的自動化流量 tracing，實現靈活智能的 API 請求防護

• 常態限流：針對客戶端和資源對象的組合和常態流量分析，定制限流規則，避免瞬時大量請求對服務端的壓力
• 容災場景熔斷：當集群出現明顯異常或者雪崩時，通過手動熔斷止損，并逐步放開限流以恢復集群正常

節點防護：異常版本升級觸發大面積驅逐

相對于控制面，數據面的版本和配置通常更加復雜多樣，迭代通常會更加頻繁，更容易因為不當的組件運維操作引發不可預期的極端風險。某次 SRE 在升級 Kubelet 版本的過程中，應用了不符合預期的混部資源配置，在 Kubelet 重啟后，大量 Running 中的 pod 因為資源歸屬識別錯誤，導致 admit 失敗而被 delete，同時，原生的 delete API 不過 PDB 攔截，預期會引發大量業務容量的損失；但由于已經上線防護能力，最終沒有引發嚴重的線上問題。在該案例中，接入防御體系能夠同時在單機和中心上提供防御能力

• 單機攔截：對于已經處于 Running 狀態的核心服務，默認補充 explict-deletion 標簽，確保只有顯式地通過 API 標記刪除 （設置 deletionTimestamp），能夠保證因為數據面異常發版后，不影響業務實例的運行，給人為介入處理提供足夠的時間
• 中心攔截：對于核心服務補充 Delete 與 DeleteCollection 兩種 API 進行校驗，避免類似非預期的刪除 pod 行為對業務造成影響

后續規劃

字節防護實踐未來會逐漸集成火山引擎 VKE 產品中，為云上的服務提供更加可靠的穩定性保證；除此之外，我們也會持續增強云原生防護的功能特性，收斂并解決更多可能對云上服務造成穩定性風險的場景，包括如下內容

• 控制面 Delete pod API 防護內建的 PDB 防護機制僅作用于 Evict pod API，校驗性能不佳。當存在大量 PDB 對象時，Evict pod API 耗時會大幅度劣化，請求時延遠超 Delete pod，因此有很多組件刻意不使用 Evict pod 而直接 Delete pod，例如調度器發起搶占等。由于控制面 Delete pod 的內置校驗較少，直接使用該接口容易導致業務 pod 的健康比例低于預期，影響業務正常運行。為避免這類風險，我們一方面需要優化 Evict pod 的性能，另一方面需要通過擴展對 Delete pod 操作進行更嚴格的校驗，以保證業務運行的 pod 健康比例不低于預期。
• 收斂靜態校驗策略當前我們在控制面做的防護工作主要依托于對 Validating Admission Webhook 機制，這一方面會 apiserver 在處理請求過程中引入額外的外部過程，提高延遲與出錯概率，另一方面也會一定程度提高集群運維的復雜度。在 Kubernetes 1.26 版本中，引入了新的 Admission Plugin，支持使用 CEL （Common Expression Language）對請求進行一些靜態校驗。后續我們會將控制面防護的一些冗余操作校驗遷移到 CEL，對上述問題進行改善。
• 場景定制防護策略對于 Redis 和分布式訓練等帶存儲狀態的業務來說，其編排模型和運維方案上有比較多的定制需求，為此，防御體系需要針對其業務特點 （如存儲分片、縱向資源調整、原地重啟等），補充完善更多精細化的策略以匹配特有的極端異常風險。

總結

本文主要介紹了字節跳動內部生產環境中 Kubernetes 應用過程中發現的主要系統風險與提出一系列防護措施。具體來說，我們從 Kubernetes 組件的交互過程的角度出發，劃分為數據、控制面、節點三個層面，并通過具體示例說明了常見問題，包括誤操作和管控組件版本錯誤等等，并且針對這些常見問題，簡單介紹了我們構建的一系列防御性措施，包括但不限于，約束組件訪問權限、主動添加冗余操作與相關校驗等等。通過這些防御性措施，我們能夠降低已知問題給業務帶來的風險，為業務提供穩定的基礎服務。

除了必要的防御性加固措施，日常維護集群時的標準化變更流程也至關重要。通過控制集群規模并充分進行灰度驗證，可以降低故障的影響范圍。在生產環境中，只有綜合利用系統自我防御性措施和標準化運維等多種手段，才能最大程度地降低風險和故障損失。