作者 | 張曉宇 阿里云云原生應用平臺技術專家，

曾凡松 阿里云云原生應用平臺高級技術專家，

張皓余 阿里云云原生應用平臺技術專家

責編 | 屠敏

在“促增長、調結構、建生態”的策略指引下，在更好地實現云原生應用平臺三年“服務 20 萬客戶、貢獻 40 億GAAP、覆蓋 100 萬開發者”目標的同時，支撐集團業務仍然是必須堅守的大本營。

在過去的2019年天貓雙11大促活動中，阿里云上下一心用最穩定的系統狀態、最流暢的產品體驗、最飽滿的服務熱情，創造了"每秒訂單峰值達到54.4萬筆"的記錄" ，征服了全球最大流量洪峰，實現了阿里巴巴核心系統100%上云等一系列目標。這些里程碑既是奇跡，也是對于我們集腋成裘工作的驗收。

作為容器&節點團隊的一個前線工作人員，我們用自己的策略和方式讓運行百萬容器的巨獸們保持穩定，成為完成這一目標下的一名合格的船員(Kubernetes crew)。

概要

“兵來將擋水來土掩”的case by case處理問題方式只會讓我們疲于奔命于各種問題的處理中。非系統化的工作不僅收效微小而且極易引入更多不確定因素。因為我們需要一個體系去應對絕大多數問題。一個好的體系應該是怎樣的呢？請允許我一一解說。

《孫子兵法·軍爭篇》有云：疾如風，其徐如林，侵掠如火，不動如山。

容器&節點在穩定性的系統性建設工作在以下4個方面踐行遵循這一原則。

疾如風

按語: 進攻則迅疾如風，撤退則去無影蹤

LivenessProbe中心管控系統

對于大規模部署并且 7x24 小時運行的服務，因為自身的缺陷或者外部環境的變化，在運行過程中可能會遇到各種各樣的異常（相信大家都有遇到過），這些異常在絕大多數情況下可以通過“重啟”來修復（重啟大法）。而對于成千甚至上萬實例的應用而言，我們無法人工的去監視應用的運行狀態，必須要一個自動化的機制。LivenessProbe正是Kubernetes提供給應用的一種自動修復機制：用戶編寫一個檢查服務是否健康的“腳本”，并配置其執行的規則，Kubernetes按照規則定期執行該腳本，如果其返回服務處于不健康的狀態且滿足配置的閾值，通過重啟容器的方式嘗試恢復。在雙11等大促階段，任何重啟容器的動作都是危險的。使用LivenessProbe管控的Kubernetes集群，在當容器LivenessProbe檢查失敗時，單機層面不會對容器自行做重啟處理，而是由中心端統一按照配置的參數對容器重啟做管控處理。

當前我們已經完成：

1. kubelet會探測”liveness健康“腳本，若出現探測失敗，這會上報conditions。
2. 現有livenessprobe控制器watch到這個狀態，根據Configmap配置的策略，容器重啟工作可以受控執行。

后續將繼續完成：

1. 支持prometheus指標采集，待運行一段時間后，根據數據統計分析出現問題的大類。
2. 支持精細化的流控重啟策略，區分應用分組維度，和宿主機維度。目的是盡量避免同應用分組的副本在被同時大量重啟。每次發生重啟行為能盡可能分散在不同宿主機上等等更加精細化的策略。
3. 和周邊組件打通，例如NPD和調度器等。

其徐如林

按語: 像樹林一樣整齊，徐徐而行，無懈可擊。

DaemonSet部署及灰度增強。

目前DaemonSet已經在很多場景下被采用或者即將被采用，主要包括：

• 運維agent 類：一般是整個集群的 node 上都會部署（無差異性）
• plugin 類：在指定機器上部署的，如CSI Plugin，device Plugin等
• 用戶自行開發的業務應用。（差異性大，需要準入機制）

然而社區原生的DaemonSet在升級和部署方面很難滿足我們的實際生產需求:

1. DaemonSet不具備暫停和等待恢復能力。尤其是在大規模集群場景下，為了維護集群的高可用和版本確定性，用戶在發布部分副本時，希望在灰度中，暫停當前版本的發布，等待和確認版本安全符合預期后再繼續灰度發布。
2. 批量部署能力缺失。對于一個成熟的系統，灰度發布能力是一項必備能力，然后社區版本在這里卻沒有做任何增強。目前基于原生版本的DaemonSet，用戶只能采用最原始的一把嗦發布策略。
3. 熱升級能力缺失。DaemonSet熱升級即DaemonSet的副本先創建，再刪除舊的副本。對于某些提供基礎服務的組件而言，服務不可中斷非常重要和敏感。例如單機上DNS解析服務容器，這項單機服務一旦服務中斷就可能導致LivenessProbe或者readnessProbe檢查失敗，或者某些敏感業務應用連接不上服務端出現各種異常報警，進而間接導致業務容器重啟以及服務中斷。

因此，我們需要提供一攬子解決方案使原生的DaemonSet在灰度能力上得到增強，以適應當前阿里巴巴經濟體需求以及推廣到社區增強影響力的需要。

節點團隊已經在原生DaemonSet workload這個基礎上完成的一些增強：

1. 新增了升級暫停和恢復能力
2. 對于RollingUpdate策略，新增分組控制能力，增加partition和selector。
3. 新增SurgingRollingUpdate策略，提供熱升級能力，即創建新版本pod，再刪除舊pod。

接下來我們還將讓DaemonSet提供更多能力，讓部署和升級變更更加順滑：

• 制定DaemonSet的評審和準入標準。
• 分批部署能力。
• 提供DaemonSet可部署節點和已部署節點的字段。 DaemonSet維度顯示部署節點和Pod信息等細節。
• 提供當前批次 部署/升級 的進度。 Partition和Selector下，顯示最近一個批次的Pod，Node狀態。
• 預先拉取鏡像問題 發布或者升級時選擇parttion模式，預先讓所有符合條件的node先拉取鏡像。
• 升級策略增加 inplacement升級 該升級策略會校驗本次升級的字段，在此策略下，僅允許修改image字段，如果修改了其他字段拒絕掉。 該升級策略實現Pod不重建，容器重建。
• SurgingRollingUpdate中增加MaxUnavailable字段 當DS的副本不可用數達到MaxUnavailabl時候，停止更新DaemonSet
• Daemonset在灰度時候遇到Node節點變化時。 節點增多，更新成舊版本的Pod。 節點減少，如果涉及Partition或者Selector選中的節點，自動訂正Selector或者Partition的范圍。
• DaemonSet中的Pod Template中新增允許策略Never，達到Broadcast job的功能。所有節點上的Pod狀態為completed后，DaemonSet狀態也是Completed。

侵掠如火

按語: 沖鋒陷陣，如烈火燎原，銳不可當

defender系統

defender是站在整個k8s集群的視角，針對用戶發起的或者系統自動發起的有風險的操作進行防護（流控、熔斷、校驗）和審計的風控系統。

之所以做defender，主要從以下幾個方面考慮:

• 類似kubelet/controller這樣的組件，在一個集群中存在多個進程，任一單一進程都無法看到全局的視圖，無法進行準確的限流。
• 從運維視角，分散在各個組件中的限速規則難以配置與審計，當部分操作因為限流原因失敗時，排查鏈路過長影響問題定位的效率。
• k8s面向終態的分布式設計，每個組件都有決策的能力，那么就需要一個集中的服務對那些危險決策進行風控。

defender的框架圖如下所示：

• defender server是k8s集群級的服務，可以部署多個，其中一個active，其余standby
• 用戶可以通過kubectl配置風控規則
• k8s中的組件，例如controller，kubelet，extension-controller等，都可以通過defender sdk接入defender（改動很小），在進行危險操作前請求defender進行風控，根據風控結果決定是否繼續該危險操作。 defender作為一個集群級的風控防護中心，為k8s集群的整體穩定性進行保駕護航。

不動如山

按語: 即便敵人攻到他腳底下，也不會起身，自有身邊衛士去廝殺

Node Problem Detection & Auto Healer節點故障檢測與自愈

1. 為了實現全網集群的節點可調度率 > 99.5%，ASI需要更加突出自動化和智能化的節點故障探測，上報，處理，愈合能力。

2. 實現約定時間內自動恢復Node可調度可使用能力，滿足1-5-10故障處理的需求。

目前現狀：

目前集團內部檢測節點監控狀況有兩個獨立的流程：

1. pouchcollector，它的主要功能是定時執行20多個檢測檢測任務。然后這些檢測結果上報給Promethues。

2. sigma-host-doctor，它是中心端在宿主機上運行巡檢腳本，再將異常展示出來。通過人工或者Cron任務去做修復工作。

接下來，我們將整合大團隊的整個能力，做出兼容并蓄的體系，它將具備：

• 利用開源軟件NPD，并做適當優化擴展，讓NPD具備熱插拔Plugin的能力。
• 容器平臺的同事根據故障類型維護不同NPD Custom plugin。
• NPD將采集數據部分export給Promethues，部分export給APIServer。
• 上層Controller根據匯總的數據結果，匹配合適的自愈策略，通過和宿主機的通道，下發故障自愈的命令。
• ...

總結

Case by case，人工干預的各種穩定性工作曾經發揮過很多救火員的作用。我們由衷對于過去的自己表示感謝。但是隨著穩定性體系化建設的推進，我們將會研發并引入更多的技術解決方案。這一過程雖然歷經坎坷，也會彎路重重，但是方向對了，就不怕路遠。在現在，在不遠的未來，我們會發現：

1. 處理線上緊急突發問題時擁有更多智能化，自動化的工具。
2. 線上各種人工手動干預操作大量減少。所有操作均有章可循，手忙腳亂和心有余悸的線上變更會塵封歷史。
3. 借助于自動修復策略的不斷收集和優化，疲于奔命地處理各類散落在各個集群的問題的情況會越來越少。程序員也可以相對愉快地享受工作。
4. 通過技術讓工程師將更多的精力投入在體系化建設和技術深度上。日常投入更少的時間和精力，但是更好地服務集團業務。用技術實現釋放紅利的正向循環。

這種組合拳的方案會解放更多生產力，給節點乃至系統穩定性建設和團隊工作氛圍建設帶來立竿見影的效果。

容器平臺的穩定性，未來已來。

更多「問底中國IT技術演進」專題精彩文章：