Kubernetes 稳定性保障手册（极简版）
作者 | 悟鵬
來源 | 阿里巴巴云原生
頭圖 |?下載于視覺中國
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 |
|
L2 |
|
L3 |
|
L4 |
|
L5 |
|
實踐
1. 方法論
1）全局視圖
實踐流程：
整理運行鏈路圖，標記鏈路是否是關鍵鏈路
基于運行鏈路圖，進行可觀測性配置
基于鏈路重要程度，進行可控性治理
為了降低實踐的成本，需要把握云產品中的元素及交互關系，從基礎的元素和交互方面解構復雜系統：
元素 (2 類)
云產品組件
云產品
交互 (2 類，共 3 種場景)
云產品內部
組件自身
組件與組件之間
云產品之間
云產品與云產品之間
如下圖：
隨著元素數量和交互關系的增多，系統會逐步變得復雜，穩定性保障面臨的挑戰也會越來越大，要避免引入非必要的復雜性。
因此，需要先梳理清楚當前的運行鏈路圖，進行鏈路重要性分析，并整理組件大圖，判斷組件的爆炸半徑。在此基礎上，還需要進行參與人員的 review，避免在人員的投入方面存在單點風險。
運行鏈路圖示例：
鏈路重要性示例：
云產品間交互示例：
基于上述對系統復雜度、運行鏈路的分析，面對穩定性保障的問題域，可以有效提出、落地解決方案。
2）問題處理
實踐流程：
長期維護角色列表、功能流程圖、運行鏈路圖
在多個分級的「告警群」中感知問題的發生和恢復
在唯一的「問題處理群」中處理問題和復盤問題
對于復雜的系統，通常會有如下的角色關系：
梳理清楚每層的角色，并使得參與同學可以方便查找目標同學，會縮短問題處理時間。
2. 問題域
1）概述
2）推薦
維度 | 項目 | 推薦 |
目標管理 | 業務 SLA | 業務相關，可參考：
|
技術 SLI / SLO | K8s 社區：
| |
可觀測性 | 日志 | 開發階段：
運行階段：
|
Metrics | 開發階段：
運行階段：
| |
巡檢 | 后續推出 | |
告警 | 基于日志、metrics、巡檢系統配置告警，配置每條告警時，可通過如下問題列表達到舉一反三效果：
| |
可控性 | 發布管理 | 后續推出 |
恢復管理 | 實踐： 枚舉異常場景 線下模擬異常 通過預案固化處理方案 挑戰：
| |
混沌工程 | 實踐：
| |
定期體檢 | 實踐：
| |
專項治理 | 復雜度治理 | 梳理：
如非必要，勿增實體。 |
爆炸半徑治理 | 實踐： 基于運行鏈路圖和鏈路重要性圖，整理鏈路和組件的爆炸半徑 進行鏈路和組建的可觀測性和可控性治理 關注：
| |
跌零因子治理 | 實踐： 爆炸半徑的極端情況 最高優先級進行可觀測性和可控性治理 線下演練 |
后續
對于《Kubernetes 穩定性保障手冊》，接下來會進行如下的章節細化，分別從方法論和工具/服務的角度進行總結，形成初版后與大家分享，敬請期待~
更多閱讀推薦
無法恢復，歐洲云服務巨頭數據中心起火
CPU 空閑時在干嘛？
低代碼，讓人人都可以是開發者
三探云原生全景圖，這次聊聊運行時層
一眼看盡5G江湖，Gartner發布5G網絡基礎設施魔力象限報告
馮諾依曼架構的 IO 鴻溝，誰能來填補？
總結
以上是生活随笔為你收集整理的Kubernetes 稳定性保障手册（极简版）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【我想进大厂】Redis夺命连环11问
- 下一篇： 小困惑，关于 Serverless 函数