一、前言

經(jīng)過(guò)超過(guò)半年的研發(fā)，螞蟻金服在今年完成了 Kubernetes 的全面落地，并使得核心鏈路100% 運(yùn)行在 Kubernetes。到今年雙十一，螞蟻金服內(nèi)部通過(guò) Kubernetes 管理了數(shù)以萬(wàn)計(jì)的機(jī)器以及數(shù)十萬(wàn)的業(yè)務(wù)實(shí)例，超過(guò)90%的業(yè)務(wù)已經(jīng)平穩(wěn)運(yùn)行在 Kubernetes 上。整個(gè)技術(shù)切換過(guò)程平穩(wěn)透明，為云原生的資源基礎(chǔ)設(shè)施演進(jìn)邁好了關(guān)鍵的一步。

本文主要介紹 Kubernetes 在螞蟻金服的使用情況，雙十一大促對(duì) Kubernetes 帶來(lái)史無(wú)前例的挑戰(zhàn)以及我們的最佳實(shí)踐。希望通過(guò)分享這些我們?cè)趯?shí)踐過(guò)程中的思考，讓大家在應(yīng)用 Kubernetes 時(shí)能夠更加輕松自如。

二、螞蟻金服的 Kubernetes 現(xiàn)狀

2.1 發(fā)展歷程與落地規(guī)模

Kubernetes 在螞蟻金服落地主要經(jīng)歷了四個(gè)階段：

1. 平臺(tái)研發(fā)階段：2018年下半年螞蟻金服和阿里集團(tuán)共同投入 Kubernetes 技術(shù)生態(tài)的研發(fā)，力求通過(guò) Kubernetes 替換內(nèi)部自研平臺(tái)；
2. 灰度驗(yàn)證：2019年初 Kubernetes 在螞蟻金服灰度落地，通過(guò)對(duì)部分資源集群進(jìn)行架構(gòu)升級(jí)以及灰度替換生產(chǎn)實(shí)例兩種方式，讓 Kubernetes 得以小規(guī)模的驗(yàn)證；
3. 云化落地（螞蟻金服內(nèi)部基礎(chǔ)設(shè)施云原生化）：2019年4月螞蟻金服內(nèi)部完成 Kubernetes 適配云化環(huán)境的目標(biāo)，并于618之前完成云化機(jī)房100% 使用 Kubernetes 的目標(biāo)，這是 Kubernetes 第一次在螞蟻金服內(nèi)部得到規(guī)?；尿?yàn)證；
4. 規(guī)模化落地：2019年618之后，螞蟻金服內(nèi)部開始全面推動(dòng) Kubernetes 落地，在大促之前完成核心鏈路100% 運(yùn)行在 Kubernetes的目標(biāo)，并完美支撐了雙十一大考。

2.2 統(tǒng)一資源調(diào)度平臺(tái)

Kubernetes 承載了螞蟻金服在云原生時(shí)代對(duì)資源調(diào)度的技術(shù)目標(biāo)：統(tǒng)一資源調(diào)度。通過(guò)統(tǒng)一資源調(diào)度，可以有效提升資源利用率，極大的節(jié)省資源成本。要做到統(tǒng)一調(diào)度，關(guān)鍵在于從資源層面將各個(gè)二層平臺(tái)的調(diào)度能力下沉，讓資源在 Kubernetes 統(tǒng)一分配。

螞蟻金服在落地 Kubernetes 實(shí)現(xiàn)統(tǒng)一調(diào)度目標(biāo)時(shí)遵循了標(biāo)準(zhǔn)化的擴(kuò)展方式：

• 一切業(yè)務(wù)擴(kuò)展均圍繞 Kubernetes APIServer，通過(guò)CRD + Operator方式完成業(yè)務(wù)功能的適配和擴(kuò)展；
• 基礎(chǔ)服務(wù)通過(guò) Node 層定義的資源接口完成個(gè)性化適配，有益于形成資源接入的最佳實(shí)踐。

得益于持續(xù)的標(biāo)準(zhǔn)化工作，我們?cè)诼涞?Kubernetes 的大半年內(nèi)應(yīng)用了多項(xiàng)技術(shù)，包含安全容器，統(tǒng)一日志，GPU 精細(xì)調(diào)度，網(wǎng)絡(luò)安全隔離及安全可信計(jì)算等，并通過(guò) Kubernetes 統(tǒng)一使用和管理這些資源服務(wù)了大量在線業(yè)務(wù)以及計(jì)算任務(wù)型業(yè)務(wù)。

三、雙十一 Kubernetes 實(shí)踐

下面我們通過(guò)以下幾種場(chǎng)景介紹螞蟻金服內(nèi)部是如何使用 Kubernetes，以及在此過(guò)程中我們面對(duì)的挑戰(zhàn)和實(shí)踐之路。

3.1 資源分時(shí)復(fù)用

在大促過(guò)程中，不同業(yè)務(wù)域的洪峰流量通常都是在不同時(shí)間段來(lái)臨，而應(yīng)對(duì)這些不同時(shí)間到來(lái)的業(yè)務(wù)流量往往都需要大量的額外計(jì)算資源做保障。在以往的幾次活動(dòng)中，我們嘗試了通過(guò)應(yīng)用快速騰挪的方式來(lái)做到資源上的分時(shí)復(fù)用，但是服務(wù)實(shí)例上下線需要預(yù)熱，騰挪耗時(shí)不可控，大規(guī)模調(diào)度的穩(wěn)定性等因素都影響了最終騰挪方案的實(shí)踐效果。

今年雙十一我們采用了資源共享調(diào)度加精細(xì)化切流的技術(shù)以達(dá)到資源分時(shí)利用的目標(biāo)，為了達(dá)到資源充分利用和極速切換的目標(biāo)，我們?cè)谝韵路矫孀隽嗽鰪?qiáng)：

• 在內(nèi)部的調(diào)度系統(tǒng)引入了聯(lián)合資源管理（Union-Resource Management），他可以將波峰波谷不重疊的業(yè)務(wù)實(shí)例擺放在相同的資源集合內(nèi)，達(dá)到最大化的資源利用。
• 研發(fā)了一套融合資源更新，流量切換及風(fēng)險(xiǎn)控制的應(yīng)用分時(shí)復(fù)用平臺(tái)，通過(guò)該平臺(tái)SRE可以快速穩(wěn)定的完成資源切換以應(yīng)對(duì)不同的業(yè)務(wù)洪峰。

整套平臺(tái)和技術(shù)最終實(shí)現(xiàn)了令人激動(dòng)的成果：螞蟻金服內(nèi)部不同業(yè)務(wù)鏈路數(shù)以萬(wàn)計(jì)的實(shí)例實(shí)現(xiàn)了最大程度的資源共享，這些共享資源的實(shí)例可分鐘級(jí)完成平滑切換。這種技術(shù)能力也突破了當(dāng)下資源水平伸縮能力的效率限制，為資源的分時(shí)復(fù)用打開了想象空間。

3.2 計(jì)算型任務(wù)混部

Kubernetes 社區(qū)的落地案例中，我們往往看到的都是各種各樣的在線業(yè)務(wù)，計(jì)算型業(yè)務(wù)往往通過(guò)“圈地”式的資源申請(qǐng)和獨(dú)立的二層調(diào)度跑在 Kuberentes 集群中。但是在螞蟻內(nèi)部我們從決定使用 Kubernetes 的第一天起，就將 Kubernetes 融合計(jì)算型業(yè)務(wù)實(shí)現(xiàn)資源的統(tǒng)一調(diào)度作為我們的目標(biāo)。

在螞蟻金服內(nèi)部我們持續(xù)的使用 Kubernetes 支持各類計(jì)算業(yè)務(wù)，例如各類AI 訓(xùn)練任務(wù)框架，批處理任務(wù)和流式計(jì)算等。他們都有一個(gè)共同的特點(diǎn)：資源按需申請(qǐng)，即用即走。

我們通過(guò) Operator 模型適配計(jì)算型任務(wù)，讓任務(wù)在真正執(zhí)行時(shí)才會(huì)調(diào)用 Kubernetes API 申請(qǐng) Pod 等資源，并在任務(wù)退出時(shí)刪除 Pod 釋放資源。同時(shí)我們?cè)谡{(diào)度引擎中引入了動(dòng)態(tài)資源調(diào)度能力和任務(wù)畫像系統(tǒng)，這為在線和計(jì)算的不同等級(jí)業(yè)務(wù)提供了分級(jí)資源保障能力，使在線業(yè)務(wù)不受影響的情況下資源被最大化的利用。

今年雙十一除了洪峰時(shí)間段（00：00~02：00），螞蟻金服 Kubernetes 上運(yùn)行的任務(wù)均未做降級(jí)，每分鐘仍有數(shù)以百計(jì)的計(jì)算任務(wù)在 Kubernetes 上申請(qǐng)和釋放。未來(lái)螞蟻金服內(nèi)部將會(huì)持續(xù)推動(dòng)業(yè)務(wù)調(diào)度融合，將 Kubernetes 打造成為資源調(diào)度的航空母艦。

3.3 規(guī)?；诵?/h3>

螞蟻金服是目前少數(shù)運(yùn)行了全球最大規(guī)模的 Kubernetes 集群的公司之一，單集群機(jī)器規(guī)模過(guò)萬(wàn)，Pods 數(shù)量數(shù)十萬(wàn)。隨著類似計(jì)算型任務(wù)混部和資源分時(shí)復(fù)用這類業(yè)務(wù)的落地，資源的動(dòng)態(tài)使用以及業(yè)務(wù)自動(dòng)化運(yùn)維都對(duì) Kubernetes 的穩(wěn)定性和性能帶來(lái)的巨大的挑戰(zhàn)。

首先需要面對(duì)的挑戰(zhàn)是調(diào)度性能，社區(qū)的調(diào)度器在5k規(guī)模測(cè)試中調(diào)度性能只有1~2 pods/s，這顯然無(wú)法滿足螞蟻金服的調(diào)度性能需求。

針對(duì)同類業(yè)務(wù)的資源需求往往相同的特點(diǎn)，我們自研了批量調(diào)度功能，再加上例如局部的filters性能優(yōu)化等工作，最終達(dá)到了百倍的調(diào)度性能提升！

在解決了調(diào)度性能問(wèn)題后，我們發(fā)現(xiàn)規(guī)?；瘓?chǎng)景下 APIServer 逐漸成為了影響 Kubernetes 可用性的關(guān)鍵組件，CRD+Operator 的靈活擴(kuò)展能力更是對(duì)集群造成巨大的壓力。業(yè)務(wù)方有100種方法可以玩垮生產(chǎn)集群，讓人防不勝防。
造成這種現(xiàn)象一方面是由于社區(qū)今年以前在規(guī)?；系耐度胼^少 APIServer 能力較弱，另一方面也是由 Operator 模式的靈活性決定。開發(fā)者在收益于 Operator 高靈活度的同時(shí)，往往為集群管理者帶來(lái)業(yè)務(wù)不受控制的風(fēng)險(xiǎn)。即使對(duì) Kubernetes 有一定熟悉程度的開發(fā)者，也很難保障自己寫出的 Operator 在生產(chǎn)中不會(huì)引爆大規(guī)模的集群。

面對(duì)這種“核按鈕”不在集群管理員手上的情況，螞蟻內(nèi)部通過(guò)兩方面入手解決規(guī)?；瘞?lái)的問(wèn)題：

1. 我們通過(guò)持續(xù)總結(jié)迭代過(guò)程中的經(jīng)驗(yàn)，形成了內(nèi)部的最佳實(shí)踐原則，以幫助業(yè)務(wù)更好的設(shè)計(jì)Operator

• CRD 在定義時(shí)需要明確未來(lái)的最大數(shù)量，大量CR 業(yè)務(wù)最好采用 aggregate-apiserver 進(jìn)行擴(kuò)展；
• CRD 必須 Namespaced scope，以控制影響范圍；
• MutatingWebhook + 資源 Update 操作會(huì)給運(yùn)行時(shí)環(huán)境帶來(lái)不可控破壞，盡量避免使用這種組合；
• 任何 controllers 都應(yīng)該使用 informers，并且對(duì)寫操作配置合理限流；
• DaemonSet 非常高階，盡量不要采用這類設(shè)計(jì)，如果必需請(qǐng)?jiān)?Kubernetes 專家的輔導(dǎo)下使用；

1. 我們已經(jīng)在 Kubernetes 實(shí)施了一系列的優(yōu)化，包含多維度流量控制，WatchCache 處理全量 List 請(qǐng)求，controller 自動(dòng)化解決更新沖突，以及 APIServer 加入自定義索引等。

通過(guò)規(guī)范和優(yōu)化，我們從 client 到 server 對(duì) API 負(fù)載做了整體鏈路的優(yōu)化，讓資源交付能力在落地的大半年內(nèi)提升了6倍，集群每周可用率達(dá)到了3個(gè)9，讓 Kubernetes 平穩(wěn)順滑的支撐了雙十一的大促。

3.4 彈性資源建站

近幾年大促螞蟻金服都會(huì)充分利用云化資源，通過(guò)快速?gòu)椥越ㄕ镜姆绞綄⑷緲I(yè)務(wù)做“臨時(shí)”擴(kuò)容，并在大促后回收站點(diǎn)釋放資源。這樣的彈性建站方式為螞蟻節(jié)省了大量的資源開支。

Kubernetes 提供了強(qiáng)大的編排能力，但集群自身的管理能力還比較薄弱。螞蟻金服從 0 開始，基于 Kubernetes on Kubernetes 和面向終態(tài)的設(shè)計(jì)思路，開發(fā)了一套管理系統(tǒng)來(lái)負(fù)責(zé)螞蟻幾十個(gè)生產(chǎn)集群的管理，提供面向大促的快速?gòu)椥越ㄕ竟δ堋?/p>

通過(guò)這種方式我們可以自動(dòng)化的完成站點(diǎn)搭建，3小時(shí)內(nèi)交付可立即使用的包含數(shù)千個(gè) Nodes 的 Kubernetes 集群。今年雙十一我們?cè)谝惶靸?nèi)交付了全部彈性云化集群，隨著技術(shù)的不斷提升和磨練，我們期望未來(lái)能夠按天交付符合業(yè)務(wù)引流標(biāo)準(zhǔn)的集群，讓螞蟻金服的站點(diǎn)隨時(shí)隨地可彈。

四、展望未來(lái)，迎接挑戰(zhàn)

云原生時(shí)代已經(jīng)到來(lái)，螞蟻金服內(nèi)部已經(jīng)通過(guò) Kubernetes 邁出了云原生基礎(chǔ)設(shè)施建設(shè)的第一步。雖然當(dāng)前在實(shí)踐中仍然有許多挑戰(zhàn)在等著我們?nèi)?yīng)對(duì)，但相信隨著我們?cè)诩夹g(shù)上持續(xù)的投入，這些問(wèn)題會(huì)一一得到解決。

4.1 平臺(tái)與租戶

當(dāng)前我們面對(duì)的一大挑戰(zhàn)是多租戶帶來(lái)的不確定性。螞蟻金服內(nèi)部不可能為每個(gè)業(yè)務(wù)部門都維護(hù)一套Kubernetes集群，而單個(gè) Kubernetes 集群的多租戶能力十分薄弱，這體現(xiàn)在以下兩個(gè)維度：

1. APIServer 和 etcd 缺少租戶級(jí)別的服務(wù)保障能力；
2. Namespace 并不能有效的隔離全部資源，并且由于Namespace 只提供了部分資源能力，對(duì)平臺(tái)型的接入方也很不友好。

未來(lái)我們會(huì)在核心能力如 Priority and Fairness for API Server Requests 以及 Virtual Cluster 上持續(xù)的做技術(shù)投入和應(yīng)用，有效保障租戶的服務(wù)能力保障和隔離。

4.2 自動(dòng)化運(yùn)維

除了資源調(diào)度，Kubernetes 下一階段的重要場(chǎng)景就是自動(dòng)化運(yùn)維。這涉及到應(yīng)用資源全生命周期的面向終態(tài)自行維護(hù)，包含但不限于資源自動(dòng)交付及故障自愈等場(chǎng)景。

隨著自動(dòng)化程度的不斷提升，如何有效控制自動(dòng)化帶來(lái)的風(fēng)險(xiǎn)，讓自動(dòng)化運(yùn)維能夠真正提升效率而不是任何時(shí)刻都需要承擔(dān)刪庫(kù)跑路的風(fēng)險(xiǎn)是接下來(lái)的一個(gè)重要難題。

螞蟻金服在落地 Kubernetes 的過(guò)程中經(jīng)歷過(guò)類似的情況：從初期高度自動(dòng)化帶來(lái)無(wú)限的興奮，到遭遇缺陷不受控制最終爆炸引發(fā)故障后的無(wú)比沮喪，這些都說(shuō)明了在 Kubernetes 上做自動(dòng)化運(yùn)維仍有很長(zhǎng)的路要走。

為此我們接下來(lái)和阿里集團(tuán)兄弟部門一起推動(dòng) Operator 的標(biāo)準(zhǔn)化工作。從接入標(biāo)準(zhǔn)，Operator 框架，灰度能力建設(shè)和控制治理上入手，讓 Kubernetes 上的自動(dòng)化運(yùn)維變的更加可視可控。

五、結(jié)束語(yǔ)

今年我們實(shí)現(xiàn)了 Kubernetes 由 0-1 的落地，經(jīng)受了雙十一雙大促真實(shí)場(chǎng)景的考驗(yàn)。但云原生的基礎(chǔ)設(shè)施建設(shè)仍是剛剛起步，接下來(lái)我們將在彈性資源交付，集群規(guī)?；?wù)以及技術(shù)風(fēng)險(xiǎn)與自動(dòng)化運(yùn)維上持續(xù)發(fā)力，以技術(shù)支撐和推動(dòng)業(yè)務(wù)服務(wù)完成云原生的落地。

最后，也歡迎志同道合的伙伴加入我們，一起參與建設(shè)云原生場(chǎng)景下的基礎(chǔ)設(shè)施！可點(diǎn)擊【金融級(jí)分布式架構(gòu)】公眾號(hào)【加入我們】-【超多崗位】 tab 獲取職位信息。

作者介紹

曹寅，螞蟻金服 Kubernetes 落地負(fù)責(zé)人，2015年加入螞蟻金服，主要從事容器技術(shù)及平臺(tái)研發(fā)相關(guān)工作，2018年開始負(fù)責(zé)螞蟻Kubernetes的研發(fā)落地。 曾在阿里云彈性計(jì)算工作四年，對(duì)云計(jì)算基礎(chǔ)設(shè)施領(lǐng)域有著深刻的理解。

公眾號(hào)：金融級(jí)分布式架構(gòu)（Antfin_SOFA）