作者 | 悟鵬

來源 | 阿里巴巴云原生

頭圖 |?下載于視覺中國

Kubernetes 在生產環境中的采用率越來越高，復雜度越來越高，由此帶來的穩定性保障的挑戰越來越大。

對于基于 Kubernetes 的云產品，穩定性保障已成為基本訴求，穩定性缺陷會給產品帶來巨大的損失，如用戶流失、用戶信心下降、產品迭代速度變慢等。

雖然基于 Kubernetes 的穩定性保障很重要，但業界缺少基于實踐的標準化穩定性保障方案，導致同樣的問題在同一產品或不同的產品中重復出現，最佳實踐不能應用在更多相同技術棧的產品中，不同產品形成的穩定性保障最佳實踐也不能互補。

為此，基于過去的開發實踐以及基于 Kubernetes 的穩定性保障經驗，嘗試形成《Kuberentes 穩定性保障手冊》，將穩定性保障最佳實踐進行沉淀，使得人人對 Kubenretes 穩定性保障的理論形成全面的理解，相應的工具和服務成為基礎設施，復用在類似技術棧的產品中，加速穩定性保障最佳實踐的傳播、迭代和應用。

本篇文章作為《Kubernetes 穩定性保障手冊》第一篇文章，以抽象穩定性保障中的核心內容，作為穩定性保障最簡使用手冊。

極簡手冊目標

• 1min 理解穩定性保障目標

• 3min 把握穩定性保障全局視圖

• 一站查找穩定性保障推薦工具或服務

穩定性保障目標

• 滿足服務或產品對穩定性的訴求

• 加速服務或產品的迭代

穩定性保障檢查項

維度	檢查項
可觀測	是否提供了 Prometheus metrics API？ 是否將日志進行了持久化？ 是否配置了監控？ 是否有對跌零因子的監控？ 是否有服務降級的監控？ 是否有限流的監控？ 是否配置了對關鍵依賴方的可用性監控？ 監控是否分級？ 是否配置了告警？ 是否有對跌零因子的告警？ 是否有服務降級的告警？ 是否有限流的告警？ 是否配置了對關鍵依賴方的可用性告警？ 告警是否分級？ 是否配置了巡檢？ 是否使用了 structured log 便于進行 log 的查詢、分析？ 服務自身及服務間交互，是否有唯一識別身份
可灰度	是否使用了具有灰度能力的 workload？ 是否具有業務維度的灰度能力？ feature 是否具有灰度能力？ feature 是否具有可控灰度 (按百分比或指定群體) 能力？
可回滾	是否使用了均有回滾能力的 workload？ 組件是否進行了版本控制？ 配置是否進行了版本控制？
可保護	是否有限流措施？ 是否有降級措施？ 是否配置了探針？ 是否配置了 livenessProbe？ 可被訪問時，是否配置了 readinessProbe？ 初始化耗時時，是否配置了 startupProbe？ 是否有快速失敗的能力？ 是否有超時結束能力？ 依賴方不可用時: 是否會持續對依賴方帶來日常或更高壓力？ 是否會對上游帶來反向壓力？(如連接數、處理延時) 己方不可用時： 對上游的影響是否可控？ 恢復時是否可以控制請求壓力？ 是否可以無損重建？ 是否多副本部署？ 是否需要配置 PodDisruptionBudget？ 是否配置了非親和性？ 是否跨 AZ 部署？ 是否有處理預案 是否均有訪問管理？ 服務是否穩定性運行，是否會影響數據資產？ 服務是否穩定性運行，是否會泄露敏感信息？ 是否區分組件處于關鍵鏈路還是旁路？ 是否有「爆炸半徑」的整理？ 是否有「跌零因子」的整理？ 是否具有功能開關，便于一鍵開啟、關閉指定功能？
可控成本	是否配置了 limit resources？ request resources 是否表征了平均使用資源量？ 變更是增加還是降低用戶成本？ 變更是增加還是降低平臺成本？
易于運維	是否可以做到變更配置時無需重建實例？ 是否有白屏化運維途徑？ 是否有「端到端管控鏈路」流程圖？ 是否有「端到端數據鏈路」流程圖？ 是否有鏈路重要程度分析？ 是否有爆炸半徑、跌零因子分析？ 是否枚舉總結了交付的能力？ 是否枚舉總結了依賴的能力？ 是否枚舉了組件、依賴方團隊和接口人？

穩定性保障級別

級別	標準
L0	可觀測、可灰度、可回滾 均不滿足
L1	可觀測、可灰度、可回滾 滿足 50% 以上要求
L2	可觀測、可灰度、可回滾 滿足 90% 以上要求
L3	可觀測、可灰度、可回滾 滿足 90% 以上要求 可保護、可控成本 滿足 50% 以上要求
L4	可觀測、可灰度、可回滾、可保護、可控成本 滿足 90% 以上要求 易于運維滿足 50% 以上要求
L5	可觀測、可灰度、可回滾、可保護、可控成本、易于運維 滿足 90% 以上要求

實踐

1. 方法論

1）全局視圖

實踐流程：

整理運行鏈路圖，標記鏈路是否是關鍵鏈路

基于運行鏈路圖，進行可觀測性配置

基于鏈路重要程度，進行可控性治理

為了降低實踐的成本，需要把握云產品中的元素及交互關系，從基礎的元素和交互方面解構復雜系統：

• 元素 (2 類)

• • 云產品組件

  • 云產品

• 交互 (2 類，共 3 種場景)

• • 云產品內部

  • • 組件自身

    • 組件與組件之間

  • 云產品之間

  • • 云產品與云產品之間

如下圖：

隨著元素數量和交互關系的增多，系統會逐步變得復雜，穩定性保障面臨的挑戰也會越來越大，要避免引入非必要的復雜性。

因此，需要先梳理清楚當前的運行鏈路圖，進行鏈路重要性分析，并整理組件大圖，判斷組件的爆炸半徑。在此基礎上，還需要進行參與人員的 review，避免在人員的投入方面存在單點風險。

運行鏈路圖示例：

鏈路重要性示例：

云產品間交互示例：

基于上述對系統復雜度、運行鏈路的分析，面對穩定性保障的問題域，可以有效提出、落地解決方案。

2）問題處理

實踐流程：

長期維護角色列表、功能流程圖、運行鏈路圖

在多個分級的「告警群」中感知問題的發生和恢復

在唯一的「問題處理群」中處理問題和復盤問題

對于復雜的系統，通常會有如下的角色關系：

梳理清楚每層的角色，并使得參與同學可以方便查找目標同學，會縮短問題處理時間。

2. 問題域

1）概述

2）推薦

維度	項目	推薦
目標管理	業務 SLA	業務相關，可參考： 阿里云 ECS SLA: link 阿里云 SLB SLA: link
	技術 SLI / SLO	K8s 社區： Kubernetes scalability and performance SLIs/SLOs:?link
可觀測性	日志	開發階段： 使用 structured logging (KEP) golang 開發者可以使用：https://github.com/kubernetes/klog 使用方法可參見：Structured Logging migration instructions 運行階段： 采集、查詢、分析、告警配置，可使用阿里云 SLS 產品：產品官網
	Metrics	開發階段： 使用 Prometheus 標準，對外提供 http metrics API metrics API 編寫可參考：Instrumenting A Go Application For Prometheus metric 名稱最佳實踐： 第一部分要起到 namespace 的作用 最后一部分起到表征單位的作用 運行階段： 采集、可視化、告警配置，可使用阿里云 ARMS Prometheus 產品：產品官網
	巡檢	后續推出
	告警	基于日志、metrics、巡檢系統配置告警，配置每條告警時，可通過如下問題列表達到舉一反三效果： 告警是否是集群級別？ 告警是否是組件級別？ 異常信息源是什么？ 精確異常特征是什么？ 模糊異常特征是什么？ 異常爆炸半徑多大？ 告警級別是什么？ 該告警已覆蓋的范圍 (集群/組件) 多大？
可控性	發布管理	后續推出
	恢復管理	實踐： 枚舉異常場景 線下模擬異常 通過預案固化處理方案 挑戰： 災備鏈路 神龍安全容器 VK+ECI 集群逃生 單集群多套管控鏈路 單 region 多套集群 (聯邦或主備模式) 跨 region 多套集群 (聯邦或主備模式)
	混沌工程	實踐： 可控故障演練 應用在導致跌零因子和有巨大爆炸半徑的場景 隨機故障演練
	定期體檢	實踐： 系統在不斷演進，需要定期從業務視角進行審視
專項治理	復雜度治理	梳理： 業務流程圖 運行鏈路圖 鏈路重要性圖 組件列表 依賴關系圖 如非必要，勿增實體。
	爆炸半徑治理	實踐： 基于運行鏈路圖和鏈路重要性圖，整理鏈路和組件的爆炸半徑 進行鏈路和組建的可觀測性和可控性治理 關注： 異常是否會隨著時間變長，導致影響規模擴大
	跌零因子治理	實踐： 爆炸半徑的極端情況 最高優先級進行可觀測性和可控性治理 線下演練

后續

對于《Kubernetes 穩定性保障手冊》，接下來會進行如下的章節細化，分別從方法論和工具/服務的角度進行總結，形成初版后與大家分享，敬請期待~

更多閱讀推薦

• 無法恢復，歐洲云服務巨頭數據中心起火
  

• CPU 空閑時在干嘛？
  

• 低代碼，讓人人都可以是開發者
  

• 三探云原生全景圖，這次聊聊運行時層
  

• 一眼看盡5G江湖，Gartner發布5G網絡基礎設施魔力象限報告
  

• 馮諾依曼架構的 IO 鴻溝，誰能來填補？

總結

以上是生活随笔為你收集整理的Kubernetes 稳定性保障手册（极简版）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。