深入Kubernetes 的“無人區” — 螞蟻金服雙十一的排程系統

一、前言

經過超過半年的研發，螞蟻金服在今年完成了 Kubernetes 的全面落地，并使得核心鍊路100% 運作在 Kubernetes。到今年雙十一，螞蟻金服内部通過 Kubernetes 管理了數以萬計的機器以及數十萬的業務執行個體，超過90%的業務已經平穩運作在 Kubernetes 上。整個技術切換過程平穩透明，為雲原生的資源基礎設施演進邁好了關鍵的一步。

本文主要介紹 Kubernetes 在螞蟻金服的使用情況，雙十一大促對 Kubernetes 帶來史無前例的挑戰以及我們的最佳實踐。希望通過分享這些我們在實踐過程中的思考，讓大家在應用 Kubernetes 時能夠更加輕松自如。

二、螞蟻金服的 Kubernetes 現狀

2.1 發展曆程與落地規模

Kubernetes 在螞蟻金服落地主要經曆了四個階段：

1. 平台研發階段：2018年下半年螞蟻金服和阿裡集團共同投入 Kubernetes 技術生态的研發，力求通過 Kubernetes 替換内部自研平台；
2. 灰階驗證：2019年初 Kubernetes 在螞蟻金服灰階落地，通過對部分資源叢集進行架構更新以及灰階替換生産執行個體兩種方式，讓 Kubernetes 得以小規模的驗證；
3. 雲化落地（螞蟻金服内部基礎設施雲原生化）：2019年4月螞蟻金服内部完成 Kubernetes 适配雲化環境的目标，并于618之前完成雲化機房100% 使用 Kubernetes 的目标，這是 Kubernetes 第一次在螞蟻金服内部得到規模化的驗證；
4. 規模化落地：2019年618之後，螞蟻金服内部開始全面推動 Kubernetes 落地，在大促之前完成核心鍊路100% 運作在 Kubernetes的目标，并完美支撐了雙十一大考。

2.2 統一資源排程平台

Kubernetes 承載了螞蟻金服在雲原生時代對資源排程的技術目标：統一資源排程。通過統一資源排程，可以有效提升資源使用率，極大的節省資源成本。要做到統一排程，關鍵在于從資源層面将各個二層平台的排程能力下沉，讓資源在 Kubernetes 統一配置設定。

螞蟻金服在落地 Kubernetes 實作統一排程目标時遵循了标準化的擴充方式：

• 一切業務擴充均圍繞 Kubernetes APIServer，通過CRD + Operator方式完成業務功能的适配和擴充；
• 基礎服務通過 Node 層定義的資源接口完成個性化适配，有益于形成資源接入的最佳實踐。

得益于持續的标準化工作，我們在落地 Kubernetes 的大半年内應用了多項技術，包含安全容器，統一日志，GPU 精細排程，網絡安全隔離及安全可信計算等，并通過 Kubernetes 統一使用和管理這些資源服務了大量線上業務以及計算任務型業務。

三、雙十一 Kubernetes 實踐

下面我們通過以下幾種場景介紹螞蟻金服内部是如何使用 Kubernetes，以及在此過程中我們面對的挑戰和實踐之路。

3.1 資源分時複用

在大促過程中，不同業務域的洪峰流量通常都是在不同時間段來臨，而應對這些不同時間到來的業務流量往往都需要大量的額外計算資源做保障。在以往的幾次活動中，我們嘗試了通過應用快速騰挪的方式來做到資源上的分時複用，但是服務執行個體上下線需要預熱，騰挪耗時不可控，大規模排程的穩定性等因素都影響了最終騰挪方案的實踐效果。

今年雙十一我們采用了資源共享排程加精細化切流的技術以達到資源分時利用的目标，為了達到資源充分利用和極速切換的目标，我們在以下方面做了增強：

• 在内部的排程系統引入了聯合資源管理（Union-Resource Management），他可以将波峰波谷不重疊的業務執行個體擺放在相同的資源集合内，達到最大化的資源利用。
• 研發了一套融合資源更新，流量切換及風險控制的應用分時複用平台，通過該平台SRE可以快速穩定的完成資源切換以應對不同的業務洪峰。

整套平台和技術最終實作了令人激動的成果：螞蟻金服内部不同業務鍊路數以萬計的執行個體實作了最大程度的資源共享，這些共享資源的執行個體可分鐘級完成平滑切換。這種技術能力也突破了當下資源水準伸縮能力的效率限制，為資源的分時複用打開了想象空間。

3.2 計算型任務混部

Kubernetes 社群的落地案例中，我們往往看到的都是各種各樣的線上業務，計算型業務往往通過“圈地”式的資源申請和獨立的二層排程跑在 Kuberentes 叢集中。但是在螞蟻内部我們從決定使用 Kubernetes 的第一天起，就将 Kubernetes 融合計算型業務實作資源的統一排程作為我們的目标。

在螞蟻金服内部我們持續的使用 Kubernetes 支援各類計算業務，例如各類AI 訓練任務架構，批處理任務和流式計算等。他們都有一個共同的特點：資源按需申請，即用即走。

我們通過 Operator 模型适配計算型任務，讓任務在真正執行時才會調用 Kubernetes API 申請 Pod 等資源，并在任務退出時删除 Pod 釋放資源。同時我們在排程引擎中引入了動态資源排程能力和任務畫像系統，這為線上和計算的不同等級業務提供了分級資源保障能力，使線上業務不受影響的情況下資源被最大化的利用。

今年雙十一除了洪峰時間段（00：00~02：00），螞蟻金服 Kubernetes 上運作的任務均未做降級，每分鐘仍有數以百計的計算任務在 Kubernetes 上申請和釋放。未來螞蟻金服内部将會持續推動業務排程融合，将 Kubernetes 打造成為資源排程的航空母艦。

3.3 規模化核心

螞蟻金服是目前少數運作了全球最大規模的 Kubernetes 叢集的公司之一，單叢集機器規模過萬，Pods 數量數十萬。随着類似計算型任務混部和資源分時複用這類業務的落地，資源的動态使用以及業務自動化運維都對 Kubernetes 的穩定性和性能帶來的巨大的挑戰。

首先需要面對的挑戰是排程性能，社群的排程器在5k規模測試中排程性能隻有1~2 pods/s，這顯然無法滿足螞蟻金服的排程性能需求。

針對同類業務的資源需求往往相同的特點，我們自研了批量排程功能，再加上例如局部的filters性能優化等工作，最終達到了百倍的排程性能提升！

在解決了排程性能問題後，我們發現規模化場景下 APIServer 逐漸成為了影響 Kubernetes 可用性的關鍵元件，CRD+Operator 的靈活擴充能力更是對叢集造成巨大的壓力。業務方有100種方法可以玩垮生産叢集，讓人防不勝防。

造成這種現象一方面是由于社群今年以前在規模化上的投入較少 APIServer 能力較弱，另一方面也是由 Operator 模式的靈活性決定。開發者在收益于 Operator 高靈活度的同時，往往為叢集管理者帶來業務不受控制的風險。即使對 Kubernetes 有一定熟悉程度的開發者，也很難保障自己寫出的 Operator 在生産中不會引爆大規模的叢集。

面對這種“核按鈕”不在叢集管理者手上的情況，螞蟻内部通過兩方面入手解決規模化帶來的問題：

1. 我們通過持續總結疊代過程中的經驗，形成了内部的最佳實踐原則，以幫助業務更好的設計Operator

• CRD 在定義時需要明确未來的最大數量，大量CR 業務最好采用 aggregate-apiserver 進行擴充；
• CRD 必須 Namespaced scope，以控制影響範圍；
• MutatingWebhook + 資源 Update 操作會給運作時環境帶來不可控破壞，盡量避免使用這種組合；
• 任何 controllers 都應該使用 informers，并且對寫操作配置合理限流；
• DaemonSet 非常高階，盡量不要采用這類設計，如果必需請在 Kubernetes 專家的輔導下使用；

1. 我們已經在 Kubernetes 實施了一系列的優化，包含多元度流量控制，WatchCache 處理全量 List 請求，controller 自動化解決更新沖突，以及 APIServer 加入自定義索引等。

通過規範和優化，我們從 client 到 server 對 API 負載做了整體鍊路的優化，讓資源傳遞能力在落地的大半年内提升了6倍，叢集每周可用率達到了3個9，讓 Kubernetes 平穩順滑的支撐了雙十一的大促。

3.4 彈性資源建站

近幾年大促螞蟻金服都會充分利用雲化資源，通過快速彈性建站的方式将全站業務做“臨時”擴容，并在大促後資源回收筒點釋放資源。這樣的彈性建站方式為螞蟻節省了大量的資源開支。

Kubernetes 提供了強大的編排能力，但叢集自身的管理能力還比較薄弱。螞蟻金服從 0 開始，基于 Kubernetes on Kubernetes 和面向終态的設計思路，開發了一套管理系統來負責螞蟻幾十個生産叢集的管理，提供面向大促的快速彈性建站功能。

通過這種方式我們可以自動化的完成站點搭建，3小時内傳遞可立即使用的包含數千個 Nodes 的 Kubernetes 叢集。今年雙十一我們在一天内傳遞了全部彈性雲化叢集，随着技術的不斷提升和磨練，我們期望未來能夠按天傳遞符合業務引流标準的叢集，讓螞蟻金服的站點随時随地可彈。

四、展望未來，迎接挑戰

雲原生時代已經到來，螞蟻金服内部已經通過 Kubernetes 邁出了雲原生基礎設施建設的第一步。雖然目前在實踐中仍然有許多挑戰在等着我們去應對，但相信随着我們在技術上持續的投入，這些問題會一一得到解決。

4.1 平台與租戶

目前我們面對的一大挑戰是多租戶帶來的不确定性。螞蟻金服内部不可能為每個業務部門都維護一套Kubernetes叢集，而單個 Kubernetes 叢集的多租戶能力十分薄弱，這展現在以下兩個次元：

1. APIServer 和 etcd 缺少租戶級别的服務保障能力；
2. Namespace 并不能有效的隔離全部資源，并且由于Namespace 隻提供了部分資源能力，對平台型的接入方也很不友好。

未來我們會在核心能力如 Priority and Fairness for API Server Requests 以及 Virtual Cluster 上持續的做技術投入和應用，有效保障租戶的服務能力保障和隔離。

4.2 自動化運維

除了資源排程，Kubernetes 下一階段的重要場景就是自動化運維。這涉及到應用資源全生命周期的面向終态自行維護，包含但不限于資源自動傳遞及故障自愈等場景。

随着自動化程度的不斷提升，如何有效控制自動化帶來的風險，讓自動化運維能夠真正提升效率而不是任何時刻都需要承擔删庫跑路的風險是接下來的一個重要難題。

螞蟻金服在落地 Kubernetes 的過程中經曆過類似的情況：從初期高度自動化帶來無限的興奮，到遭遇缺陷不受控制最終爆炸引發故障後的無比沮喪，這些都說明了在 Kubernetes 上做自動化運維仍有很長的路要走。

為此我們接下來和阿裡集團兄弟部門一起推動 Operator 的标準化工作。從接入标準，Operator 架構，灰階能力建設和控制治理上入手，讓 Kubernetes 上的自動化運維變的更加可視可控。

五、結束語

今年我們實作了 Kubernetes 由 0-1 的落地，經受了雙十一雙大促真實場景的考驗。但雲原生的基礎設施建設仍是剛剛起步，接下來我們将在彈性資源傳遞，叢集規模化服務以及技術風險與自動化運維上持續發力，以技術支撐和推動業務服務完成雲原生的落地。

最後，也歡迎志同道合的夥伴加入我們，一起參與建設雲原生場景下的基礎設施！可點選【金融級分布式架構】公衆号【加入我們】-【超多崗位】 tab 擷取職位資訊。

作者介紹

曹寅，螞蟻金服 Kubernetes 落地負責人，2015年加入螞蟻金服，主要從事容器技術及平台研發相關工作，2018年開始負責螞蟻Kubernetes的研發落地。 曾在阿裡雲彈性計算工作四年，對雲計算基礎設施領域有着深刻的了解。