云計算的競爭曠日持久，表面看來格局初定，內(nèi)里卻在醞釀巨變。
具有先發(fā)優(yōu)勢的玩家，好不容易取得了看似不可撼動的地位，不曾想到有朝一日會中途被拉到同一起跑線，更換新的“CloudOS”重新出發(fā)。這個局面恐怕連 Kubernetes 早期創(chuàng)始人都會覺得不可思議。他當(dāng)初只是想改變現(xiàn)狀，在亞馬遜的主導(dǎo)地位下，讓谷歌取得一戰(zhàn)之力。
2014 年，谷歌開源了 Kubernetes，紅帽、騰訊、阿里、華為等國內(nèi)外一眾廠商開始力出一處，共同推進(jìn) Kubernetes 的采用。2017 年底，就連亞馬遜也推出了 Kubernetes 產(chǎn)品，這也是 Kubernetes 成為標(biāo)準(zhǔn)化技術(shù)的最大信號之一。
這最終改變了整個云計算。
大家都開始基于 Kubernetes 技術(shù)生態(tài)去構(gòu)建公有云產(chǎn)品，基于統(tǒng)一的標(biāo)準(zhǔn)以避免“深度綁定”，但這也讓云原生行業(yè)嚴(yán)重同質(zhì)化，因為各個云廠商所提供的功能和服務(wù)并沒有太大的不同。對一些廠商來說，那些當(dāng)年引以為豪的自研技術(shù)突破，那些樹立在公司門口的紀(jì)念碑，那些專有性產(chǎn)品優(yōu)勢，都被抹平，這是一件非常殘酷的事情。
同時這又是一些公有云廠商重塑格局的機會。錨定 Kubernetes 進(jìn)行云原生改造，相當(dāng)于給公有云更換“技術(shù)底座”，并由此構(gòu)建出一些新的競爭力，從而贏取更多用戶。
這場技術(shù)改造，難點在哪里?
對于騰訊來說，這不僅僅是一次技術(shù)“改造”，還兼帶著騰訊全體系“自研業(yè)務(wù)上云”的戰(zhàn)略任務(wù)。
在谷歌 GKE 之后，騰訊云于 2017 年推出了 TKE。但騰訊云對外服務(wù)時，還是會面臨客戶的質(zhì)疑：“為什么騰訊自己的業(yè)務(wù)沒有使用騰訊公有云，是不是不敢用?”
騰訊這次“云原生改造 + 上云”的價值就藏在客戶的拷問中。騰訊在這二十年里，發(fā)展出了包括社交、音視頻、游戲在內(nèi)的多種業(yè)務(wù)，每種業(yè)務(wù)又都擁有海量的用戶。全面上云騰訊不是第一家，但騰訊是擁有最復(fù)雜的業(yè)務(wù)場景的一家，在這個過程中，需要結(jié)合業(yè)務(wù)制定各種各樣的技術(shù)方案，來滿足不同的業(yè)務(wù)訴求。可以理解為，每個業(yè)務(wù)的痛點都有局部最優(yōu)解，而全面上云，則是在云上尋求通用最優(yōu)解。如果這些痛點都能解決，那這樣的云服務(wù)是能有信心服務(wù)好客戶的。
要運行這么多業(yè)務(wù)，云原生底座也不能有短板，必須承載得了微信、QQ、音視頻、游戲等自研業(yè)務(wù)所有需求和核心能力，并最終將這些業(yè)務(wù)的技術(shù)積累和技術(shù)優(yōu)勢反向復(fù)制到到公有云上，服務(wù)于外部用戶。
除此之外，云原生改造還對組織能力提出了考驗。
在移動互聯(lián)網(wǎng)時代，騰訊發(fā)展出了自己的技術(shù)哲學(xué)：每個業(yè)務(wù)都有自己的技術(shù)團(tuán)隊，每個團(tuán)隊都要打勝仗，這就要求“小、快、靈”，要有閉環(huán)。在自研業(yè)務(wù)上云之前，騰訊的每一個業(yè)務(wù)都有自己完整的技術(shù)棧，內(nèi)部業(yè)務(wù)在一定程度上形成了“部門墻”效應(yīng)。并且因為技術(shù)棧不同，員工從一個業(yè)務(wù)轉(zhuǎn)崗到另一個業(yè)務(wù)，需要重新學(xué)習(xí)一遍技術(shù)，這跟換公司沒什么區(qū)別。
根據(jù)財報數(shù)據(jù)，騰訊員工已超十萬人，其中超過 7 成是技術(shù)人員，這是一次集體向云的遷移，就像一次“搬家”，但又不僅僅是將行李打包那么簡單，它是將具有一二十年歷史的不同特色的多個“大建筑”，制定“平移”方案遷移到新環(huán)境中繼續(xù)安然運行，難度可謂前所未有的高。考慮到花費的時間、涉及到的人員規(guī)模、技術(shù)深度，這個項目可能是在世界范圍內(nèi)也很難找到的超級“軟件工程”實踐。這樣的改造，過程中既有高層的推進(jìn)、動員，也有執(zhí)行層的博弈、妥協(xié)，最終實現(xiàn)了用一個點調(diào)動全局，讓全公司的技術(shù)團(tuán)隊得到了一次很好的穿透對齊，讓分散的技術(shù)能力得以統(tǒng)一。
有人說，評估騰訊云水平如何，應(yīng)該參看自研業(yè)務(wù)上云后的整體水平和運轉(zhuǎn)情況。
去年，騰訊自研業(yè)務(wù)初步完成了全部的云原生技術(shù)改造，騰訊云將所有的底層資源合并到一起進(jìn)行統(tǒng)一管理和調(diào)度，自研業(yè)務(wù)上云規(guī)模突破 5000 萬核，TKE 的在離線業(yè)務(wù)混部能力使服務(wù)器資源利用率從 30%提升至 65%，遠(yuǎn)遠(yuǎn)高于改造之前。2020年，線上會議需求爆發(fā)，騰訊云組織了幾十號人，花了8天緊急擴(kuò)容100萬核，創(chuàng)下了中國云計算史上的一個記錄。而全部上云之后，放到現(xiàn)在這個階段，利用一鍵擴(kuò)縮容，騰訊會議再要去擴(kuò)容 100 萬核，那就是幾十分鐘的事情。
所以，這次云原生改造的好處顯而易見：對外，在垂直場景沉淀下來的技術(shù)能力，讓騰訊云原生獲得了差異化的產(chǎn)品能力，能真正解決用戶在各種場景下的業(yè)務(wù)痛點;對內(nèi)，讓騰訊在云端整體的資源利用率有了一個大幅提升，這本身就是巨大的降本增效。
然而，這個過程卻是經(jīng)過了千辛萬苦。
“像下一盤棋”
2018 年，云原生行業(yè)發(fā)展趨勢初定。
隨著云原生技術(shù)的興起，騰訊內(nèi)部幾萬研發(fā)人員的技術(shù)焦慮逐漸加深。早期騰訊積累了大量的技術(shù)架構(gòu)理念，技術(shù)人員有非常強烈的自豪感，但是越是成功的組織慣性就越大，騰訊內(nèi)部很多技術(shù)理念和流程還停留在上一個時代。據(jù)稱，那時候騰訊內(nèi)部討論平臺“樂問”上充滿了技術(shù)人員的吐槽和爭議。
除了“部門墻”的存在，每個業(yè)務(wù)部門為了應(yīng)對突發(fā)的流量，在升級服務(wù)器資源時會留出資源緩沖區(qū)，當(dāng)所有的緩沖區(qū)疊加在一起，就形成了大量的閑置資源浪費。所以，無論是從技術(shù)還是資源的角度來看，上云并進(jìn)行統(tǒng)一的調(diào)度在當(dāng)時已經(jīng)是不得不做的事情。
2018 年底騰訊開了一次高層決策會議，決定將公司內(nèi)部所有平臺合到一起推行 K8s，開始進(jìn)行徹底的技術(shù)更新?lián)Q代。
這個事情一開始由鄒輝領(lǐng)導(dǎo)的 TKE 團(tuán)隊牽頭。TKE 團(tuán)隊主要由一批資深技術(shù)人員構(gòu)成，成員基本都在 30 歲以上，資歷以 10 級、11 級為主，團(tuán)隊對成員的技術(shù)能力和業(yè)務(wù)理解能力要求很高。
決策已定，但是在執(zhí)行過程中，尤其是 TKE 團(tuán)隊，前半年時間并不是真正的去做技術(shù)工作，而是跟騰訊內(nèi)部幾個事業(yè)群的平臺技術(shù)團(tuán)隊去聊需求聊具體的改造方案，他們發(fā)現(xiàn)還是存在很大的技術(shù)阻力。
騰訊云事業(yè)部門在 2016 年下半年的時候就啟動基于 K8s 的 TKE 項目，但騰訊內(nèi)部不同 BG 存在不同的路線，有的基于 Docker，有的基于 Mesos。現(xiàn)在要將所有東西都統(tǒng)一到標(biāo)準(zhǔn)的公有云 TKE 上去，其實內(nèi)部技術(shù)團(tuán)隊難免會心生疑惑：你們是不是要過來搶我們的活?
為了減輕這些問題帶來的阻力，當(dāng)時騰訊沒有采取調(diào)整團(tuán)隊人員和效仿建立技術(shù)中臺的方式，而是制定了開源協(xié)同技術(shù)戰(zhàn)略，把公司內(nèi)部所有做相似事情的團(tuán)隊整合在一起，采取類似于外部開源運作的方式協(xié)同工作。這樣既解決了技術(shù)浪費的問題，又可以去中心化，保持快速響應(yīng)，還能更好地滿足業(yè)務(wù)需求。騰訊內(nèi)部把這種模式稱為 OTeam。OTeam 掛在公司技術(shù)委員會下面。由這七八個平臺組成的 K8s OTeam 就是一個典型的例子，它是騰訊首批三個開源協(xié)同項目之一。
在解決了技術(shù)團(tuán)隊的顧慮之后，騰訊從高層開始推進(jìn)，說服自研業(yè)務(wù)團(tuán)隊上云，同時打通職級晉升體系，通過設(shè)置公司級的專項大獎、普及云原生知識、改造進(jìn)度榜單晾曬等，從多個方面入手提高大家積極性，依照三年規(guī)劃，有步驟地進(jìn)行云原生改造和上云。
如何用好開源技術(shù)?
其實在上云決策制定之前，騰訊云已經(jīng)花了兩三年時間做了一個 TKE“原型”，也踩過了不少坑。
K8s 本身只是一個主要做容器編排調(diào)度的開源項目，TKE 底層是基于標(biāo)準(zhǔn)的 K8s，再在上面進(jìn)行產(chǎn)品化，將 K8s 和網(wǎng)絡(luò)能力、存儲能力、日志監(jiān)控等能力對應(yīng)的網(wǎng)絡(luò)產(chǎn)品、計算產(chǎn)品、日志產(chǎn)品、監(jiān)控產(chǎn)品對接整合，給用戶提供一個開箱即用的 K8s 產(chǎn)品，所以 TKE 對接了騰訊底層的各種 IaaS 產(chǎn)品能力。
2016 年騰訊開始做 TKE 的時候，國內(nèi)都還沒上 K8s 服務(wù)，業(yè)界比較好的產(chǎn)品設(shè)計也就是谷歌的 GKE，一切都是摸索著來。最開始，TKE 團(tuán)隊試圖在云上提供一站式的 K8s 服務(wù)，將 K8s 的概念進(jìn)行了一些簡化，希望通過幫用戶降低使用 K8s 的成本、讓用戶愿意直接接入 K8s，但最終發(fā)現(xiàn)這條路線是錯的。
他們發(fā)現(xiàn) K8s 不是直接面向終端用戶的，而是面向一個企業(yè)內(nèi)的 Infra 平臺團(tuán)隊的。應(yīng)該由 Infra 團(tuán)隊基于 K8s 構(gòu)建自己的 PaaS 平臺，提供給公司使用。“它是個 Kernel，是云的操作系統(tǒng)的內(nèi)核、不是 PaaS。”于 2016 年加入 TKE 團(tuán)隊，一直負(fù)責(zé) K8s 產(chǎn)品化相關(guān)工作的于廣游表示。“我們沒有意識到這樣一個核心設(shè)計的本質(zhì)。最開始，我們對它的理解有偏差，所以我們犯了一個錯誤，走了一些彎路。早期的時候為了面向業(yè)務(wù)有一些改動，意識到錯誤后，在 17 年底、18 年初的時候就糾正了。后來才變成了我們現(xiàn)在 TKE 的形態(tài)，我們也因此做了一次產(chǎn)品改名，從 CCS 改名為 TKE(Tencent Kubernetes Engine)。”
到了 2018 年，騰訊啟動開源協(xié)同之后，因為這七八個不同的容器平臺團(tuán)隊，各自都有各自的優(yōu)勢，如果要融成一個標(biāo)準(zhǔn) K8s 技術(shù)，該怎么做?TKE 要么選擇都不接收、全部“作廢”重來，要么選擇將所有的歷史包袱都背起來。K8s OTeam 在一起討論之后，選擇了后者。
這也是為了上云而做出的妥協(xié)。整個公司“像下一盤棋”，下棋是核心矛盾，往 K8s 里貢獻(xiàn)不好維護(hù)的代碼是當(dāng)時的次要矛盾。據(jù)鄒輝和于廣游回憶，當(dāng)時很快每一個團(tuán)隊都用上了 K8s，大家也都更加深刻地理解 K8s 了，理解到往 K8s 里面去改太多的邏輯，不是最優(yōu)的方式。有了這個共識之后，K8s OTeam 團(tuán)隊在不更改 K8s 主線代碼情況下，差不多用了一年時間，真的就把七八個平臺所有的功能、核心技術(shù)特長全部融入到了 TKE 容器平臺上。
大家在 K8s 基礎(chǔ)上去添加功能，且無需向用戶暴露 K8s 的基本概念，那么“零 K8s 基礎(chǔ)”的用戶也能快速部署應(yīng)用并管理其監(jiān)控、日志、服務(wù)注冊在內(nèi)的整個生命周期。后來騰訊創(chuàng)建了一套應(yīng)用模型 Tencent Application Definition(簡稱TAD)，直接使用應(yīng)用管理平臺，用戶不需要去感知 K8s 細(xì)節(jié)，極大地降低了容器使用門檻。同時也引入了插件機制，復(fù)用了 K8s 的框架，可以像寫 K8s 插件一樣寫 TKE 插件，方便第三方開發(fā)。
騰訊云原生底座的“養(yǎng)成”計劃
相比公有云外部客戶的業(yè)務(wù)，騰訊自研業(yè)務(wù)的體量更大，技術(shù)積累更深厚，測試標(biāo)準(zhǔn)也更全面和嚴(yán)苛，業(yè)務(wù)也千差萬別。
一開始，K8s 很多能力不支持，業(yè)務(wù)很難平滑切換。在 2019 年之前，大部分業(yè)務(wù)還是基于虛擬機的方式去上云，因為自己的 IDC 物理機切到云上的虛擬機之后，這個過程業(yè)務(wù)基本上沒有感知，整個架構(gòu)和代碼不需要任何的改造。但是業(yè)務(wù)上虛擬機違背了上云本質(zhì)訴求，即希望利用云原生的快速彈性伸縮能力，和統(tǒng)一資源池的其他一些能力去提升各個業(yè)務(wù)團(tuán)隊的研發(fā)效能，所以最終 TKE 團(tuán)隊還是需要幫助業(yè)務(wù)從虛擬機切到容器化，并提供相應(yīng)的產(chǎn)品能力。
TKE 平臺在初期選擇的更多還是一些無狀態(tài)的業(yè)務(wù)，先讓這些無狀態(tài)的業(yè)務(wù)能夠快速搬到云上完成改造。團(tuán)隊選擇了一些平臺的核心能力去解決業(yè)務(wù)痛點，比如說“發(fā)布”的問題。
在公有云場景下大家使用的是 K8s 基本的發(fā)布能力，比如基于滾動的發(fā)布。滾動發(fā)布過程可控性很差，遇到了問題后回滾，整個發(fā)布就會中斷。騰訊自研業(yè)務(wù)需要滿足灰度發(fā)布的要求，灰度發(fā)布對業(yè)務(wù)來說也是非常關(guān)鍵的一項能力。為了保證服務(wù)的質(zhì)量，業(yè)務(wù)團(tuán)隊要求能夠非常精準(zhǔn)地控制發(fā)布頻率、節(jié)奏和容錯，做到發(fā)布過程一切盡在掌控之中。針對這樣的需求，TKE 在自定義工作負(fù)載基礎(chǔ)之上發(fā)布了一套灰度發(fā)布策略，業(yè)務(wù)可以指定要發(fā)布的 Pod，可以按照一定的百分比進(jìn)行發(fā)布，也可以設(shè)置升級失敗的比例來實現(xiàn)暫停或回滾。
同時 TKE 也給業(yè)務(wù)提供了一些虛擬機提供不了的能力，比如動態(tài)路由能力，在容器銷毀時，平臺會將對應(yīng)路由去掉，在容器起來后，平臺會自動將容器加到路由中。使用虛擬機，業(yè)務(wù)需要自己去配置，使用容器之后，就不需要去管理業(yè)務(wù)的路由了，通過 K8s Operater 的機制已經(jīng)實現(xiàn)自動化。如此一來，大家開始初步感知到容器帶來的效率價值。
另外一個好處則是彈性伸縮和健康感知。之前使用虛擬機部署業(yè)務(wù)時，需要用戶先購買虛擬機，再在虛擬機里去部署業(yè)務(wù)的包，再確認(rèn)業(yè)務(wù)進(jìn)程健康拉起運行，最后對路由進(jìn)行管理......這個流程在接入容器之后可以大幅簡化，通過配置自動擴(kuò)縮容的能力，或者手動觸發(fā)，修改副本數(shù)后，后面所有的流程都是自動化的，可以做到秒級創(chuàng)建一批 Pod、自動感知實例健康狀態(tài)并添加到服務(wù)路由里去，業(yè)務(wù)擴(kuò)容非常絲滑。
還有就是成本上的優(yōu)勢，尤其是這幾年，所有業(yè)務(wù)成本壓力都比較大。容器在的優(yōu)勢是按量計費，Pod 銷毀了就不收費了，計費粒度是秒級的，但虛擬機不一樣，它的生命周期更重一些，彈性能力也比容器差，計費粒度也更粗。
此外，騰訊垂直業(yè)務(wù)場景也會給容器平臺提出不一樣的需求，為了滿足這些需求，TKE 反之也給自己帶來了差異化能力，這些最終都轉(zhuǎn)變?yōu)榱蓑v訊云原生產(chǎn)品的競爭力。
從垂直場景走出來的通用產(chǎn)品競爭力
從 2020 年下半年開始，騰訊游戲共有十多款產(chǎn)品陸續(xù)推動云原生改造，轉(zhuǎn)向微服務(wù)架構(gòu)。游戲是騰訊所有業(yè)務(wù)里軟件結(jié)構(gòu)比較特殊的一個，游戲服務(wù)的鏡像一般比較大，有的甚至達(dá)到十幾 GB。而我們每啟動或更新一個容器，就需要將對應(yīng)的應(yīng)用程序從遠(yuǎn)端拉到本地的機器上啟動，這么大的鏡像，在部署的時候，并發(fā)對網(wǎng)絡(luò)要求很高，源端就成了一個瓶頸。
為了解決這個問題，Oteam 團(tuán)隊在 會議上討論了很多次，商量出了一套“鏡像分發(fā)系統(tǒng)”的解決方法，類似 P2P 下載網(wǎng)狀結(jié)構(gòu)，避免源端成為瓶頸點。據(jù)騰訊游戲介紹：“云原生架構(gòu)里基于容器的快速擴(kuò)縮容，是以分鐘級、秒級來實現(xiàn)的，以前我們只能以十分鐘為單位。”
提高鏡像分發(fā)的效率，不僅僅是有益于游戲場景。在一些 AI 訓(xùn)練場景中，鏡像甚至更大，幾十 GB 也不少見，如果是需要發(fā)布成千上萬個 Pod，那就需要幾十分鐘，甚至更長時間，所以現(xiàn)在這種解決方案同樣也可以適用于大規(guī)模訓(xùn)練場景。
而在騰訊會議以及其他社交場景中，也有一些特殊要求，這種服務(wù)往往含有大量的會話信息，很多是長連接，有些業(yè)務(wù)還會大量使用共享內(nèi)存，這些都屬于有狀態(tài)的服務(wù)。
無狀態(tài)的容器擴(kuò)縮容相對簡單，但有狀態(tài)的服務(wù)要去享受容器化的灰度發(fā)布、彈性伸縮能力，難度很大，需要對業(yè)務(wù)架構(gòu)進(jìn)行大量改造。因為業(yè)務(wù)不可能在短時間內(nèi)做存算分離，把存儲層下沉、上層邏輯層做成一個無狀態(tài)的服務(wù)。所以容器就必須扛起這個責(zé)任，基于業(yè)務(wù)的這些特殊需求，在容器層適配有狀態(tài)服務(wù)。
在有狀態(tài)的服務(wù)中，如果在升級過程中對應(yīng)容器的中斷時間達(dá)到秒級，用戶通話就會出現(xiàn)延遲和卡頓，所以在升級過程中就要保證 Pod 容器的中斷時間控制在一秒以內(nèi)。TKE 團(tuán)隊實現(xiàn)了一種自定義工作負(fù)載，將新版本業(yè)務(wù)鏡像提前下載到 Pod 里，通過文件鎖和容器狀態(tài)探測機制來控制老版本和新版本之間的快速切換，將升級的中斷時間控制在毫秒級別。
另一個不得不提的是原地升級的能力，比如說容器擴(kuò)容的時候，不是通過銷毀重建的方法擴(kuò)容，而是通過原地?zé)o感知的提升擴(kuò)容。比如一般公有云對 4 核 8G 的容器進(jìn)行擴(kuò)容，會將其銷毀重新創(chuàng)一個 8 核 16G 的，這種對業(yè)務(wù)是有感知的。TKE 實現(xiàn)了更快速的原地升配，可以將 4 核 8G 的容器原地變成 8 核 16G，但業(yè)務(wù)對此是無感的，除此之外，還支持分批原地更新 Probe、Image 等能力。
另外，這幾年騰訊會議經(jīng)常遇到用戶人數(shù)突然暴增的情況，比如每年 9 月 1 號秋季開學(xué)的時候，騰訊會議的用戶量就會漲好幾倍。騰訊會議應(yīng)用程序內(nèi)部有大大小小幾百個模塊，一個應(yīng)用下面可能就包含幾十個模塊，運維人員需要做大量的緊急擴(kuò)充容，手動完成一次對應(yīng)用的擴(kuò)縮容，針對這幾十個模塊進(jìn)行操作，可能要投入很多的人力，需要很長的時間。
為了減輕運維負(fù)擔(dān)，TKE 團(tuán)隊實現(xiàn)了基于 PCU，即同時最大在線人數(shù)，這么一個指標(biāo)去做一鍵擴(kuò)縮容的功能。比如說現(xiàn)在騰訊會議在第一天的同時最大在線人數(shù) PCU 是一千萬人，以此預(yù)測，第二天可能就是兩千萬人，那意味著騰訊會議的上下游整個鏈路基本上要擴(kuò)容一倍。之前運維要去做這個事情，得去找整個騰訊會議幾萬個 Workload，然后對每個 Workload 將副本數(shù)擴(kuò)一倍。為了提升這里的效率，騰訊自研了云原生全局一鍵擴(kuò)縮容的產(chǎn)品能力，將整個騰訊會議關(guān)聯(lián)的這些 Workload 構(gòu)建成一個或者若干個業(yè)務(wù)拓?fù)洌粋€業(yè)務(wù)拓?fù)鋬?nèi)的 Workloads 支持等比例的一鍵擴(kuò)縮容。
“我記得在早期的時候，騰訊會議這幾百個模塊，擴(kuò)容幾十萬核可能要花個近半天時間，但我們把這個能力實現(xiàn)后，當(dāng)大家再面對這種擴(kuò)縮容場景時，20 分鐘左右就能完成這幾百個模塊的共計幾十萬核的擴(kuò)縮容。”
這種基于業(yè)務(wù)拓?fù)涞娜謹(jǐn)U縮容能力其實是一種普適性的大規(guī)模業(yè)務(wù)訴求，很多業(yè)務(wù)做活動都會基于一個北極星指標(biāo)來進(jìn)行容量評估。針對這個通用的需求，TKE 團(tuán)隊將之提煉成一個通用的產(chǎn)品能力，在 TKE 平臺上形成了一個全局的(跨地域、跨集群)、基于業(yè)務(wù)拓?fù)涞囊绘I擴(kuò)縮容的產(chǎn)品功能。
通過上面這些一個個的貼近真實業(yè)務(wù)的“小細(xì)節(jié)”，我們可以看出騰訊做云原生的思路是希望讓用戶的付出和痛苦最小、收益最大，盡量減少業(yè)務(wù)架構(gòu)的改造，減少運維的壓力。而且這些動態(tài)路由、無感升級等功能，王濤表示不僅僅是內(nèi)部自研業(yè)務(wù)需要，“我發(fā)現(xiàn)很多外部客戶平時都有類似的這種需求，他們也急需要這樣的一些產(chǎn)品能力，這也推動著我們將這些能力從內(nèi)部推到公有云上去，提供給外部客戶。所以，我們在騰訊自研業(yè)務(wù)上打磨的這些能力也變成了騰訊云產(chǎn)品的一個優(yōu)勢。”
深水區(qū)的那些痛
騰訊花了一年半的時間，將無狀態(tài)業(yè)務(wù)搬到了云原生平臺，幾乎把能踩的坑都踩了一遍，為后續(xù)其他業(yè)務(wù)上云鋪平了道路。這也證明了上云是可行的，給了業(yè)務(wù)團(tuán)隊更大的信心，后面就有更多業(yè)務(wù)滾雪球式地自發(fā)接入了。到了 2020 年底，上云的自研業(yè)務(wù)已經(jīng)達(dá)到了三四百萬核心的規(guī)模，平臺也運行得非常穩(wěn)定，所以 TKE 團(tuán)隊開始通過提升資源利用率、降低成本，來證明云原生確實能夠給業(yè)務(wù)和公司帶來很多實實在在的好處。
經(jīng)過 2021 年整整一年時間，通過一系列的技術(shù)手段，團(tuán)隊把一些混部集群的利用率提升到了 65%。
同時在一些業(yè)務(wù)層面，一些有狀態(tài)的業(yè)務(wù)，比如說像 Redis 數(shù)據(jù)庫、中間件、一些大數(shù)據(jù)的套件，也做了原生改造，逐步搬到了整個云原生平臺上來，騰訊內(nèi)部數(shù)據(jù)庫團(tuán)隊進(jìn)一步開發(fā)了“云巢”云原生有狀態(tài)服務(wù)平臺。這個階段差不多也用了一年時間，最終到 2022 年，也就是到去年為止，整個騰訊內(nèi)部的資源業(yè)務(wù)基本上完成了上云，整體資源達(dá)到了 5000 萬核，3 年累計節(jié)省 30 億。騰訊云包含了混部解決方案的開源項目 Crane 也經(jīng)過認(rèn)證，成為 FinOps 全球首個認(rèn)證降本增效開源方案。
在這個過程中，TKE 團(tuán)隊在調(diào)度層面做了大量的工作。
在統(tǒng)一資源池中，資源分散在不同的 K8s 集群里，不同 K8s 集群的資源利用率參差不齊;資源需要在不同 K8s 集群之間流轉(zhuǎn)，將閑置機器騰挪到繁忙的集群中，讓每個集群的資源率都非常高，這個工作是特別困難的。
最開始，TKE 團(tuán)隊嘗試優(yōu)化每一個集群的資源利用率，同時通過在離線混部，把每一個集群中的額外的資源抽離到另外的算力平臺中，進(jìn)行統(tǒng)一的調(diào)度。這雖然緩解了很多問題，但隨著利用率越來越高，干擾的問題還是會存在。為了解決這個問題，TKE 團(tuán)隊引入了新的統(tǒng)一調(diào)度方案，讓 K8s 不再負(fù)責(zé)調(diào)度，只負(fù)責(zé) Pod 的管理，真正去分配資源的時候，是將請求給到了 Serverless 調(diào)度器進(jìn)行統(tǒng)一調(diào)度，解決資源使用不均的問題。
同時，因為 K8s 自帶的原生 HPA 控制器，在這種大規(guī)模場景下，擴(kuò)縮容會有非常大的性能問題，比如在業(yè)務(wù)流量的洪峰來臨時來不及擴(kuò)容，或流量出現(xiàn)抖動。所以騰訊將原來的控制器從 K8s 里剝離出來，單獨部署，這樣就可以進(jìn)行單獨的一些管理，如高可用、容災(zāi)等，同時對控制器里的內(nèi)部實現(xiàn)邏輯做一些性能優(yōu)化，來滿足這種大規(guī)模場景下業(yè)務(wù)需要的秒級的彈性擴(kuò)縮容的能力。
沉淀多集群管理能力
前兩三年云原生行業(yè)都在“卷”單集群規(guī)模，通過優(yōu)化 ETCD、API Server、Controller 調(diào)度器的性能，將單集群的節(jié)點規(guī)模做大，達(dá)到上萬節(jié)點。但最后瓶頸還是很明顯，做到 5K 個節(jié)點集群跟一萬節(jié)點的集群，本質(zhì)上沒有帶來很大的業(yè)務(wù)價值，反而一旦單集群出現(xiàn)故障，爆炸半徑會很大。
所以，在騰訊看來，一味地去突破單集群性能不是一個正確的技術(shù)路線。
最近整個社區(qū)，包括騰訊主要投入做多集群的管理。單集群做得更小，比如說兩千個節(jié)點，甚至幾百個節(jié)點就行;但是讓更多的集群組合在一起，通過多集群的調(diào)度管理，讓它看起來像一個集群，通過這種方式去擴(kuò)展整個底層資源池的規(guī)模。
TKE 沉淀了各種多集群管理的能力，讓上層的這種多集群管理能夠去統(tǒng)一調(diào)度管理跨分區(qū)、跨地域的多集群資源。在此基礎(chǔ)上，再重點解決了從面向集群到面向應(yīng)用的調(diào)度編排問題。
這在部署全球化的業(yè)務(wù)時非常有幫助。原生 K8s 是面向集群的一套編排調(diào)度系統(tǒng)，用戶感知的是集群里面的 K8s 對象，沒有提供基于可用區(qū)容量感知調(diào)度、副本分配策略決策這些調(diào)度能力。比如一個業(yè)務(wù)全網(wǎng)有一萬個工作負(fù)載、五萬個 Pod，分布在全球十七個地域，共八十多個集群。如果要對這個業(yè)務(wù)做一次全網(wǎng)變更，按照以前面向集群的方式效率非常低。
所以騰訊云原生團(tuán)隊抽象出了面向應(yīng)用的能力，對跨集群應(yīng)用的統(tǒng)一變更，提供了一個應(yīng)用管理平臺，用統(tǒng)一的看板跟蹤發(fā)布是否正常。業(yè)務(wù)部署后還要能從視圖看到部署的容災(zāi)是不是合理的，所以要有多地域的容災(zāi)檢測。平臺也可以根據(jù)用戶定義好容災(zāi)部署策略進(jìn)行巡檢，出了異常可以自動告警。在面向全球化上，用戶還可以利用全局一鍵擴(kuò)縮容能力，對海外和國內(nèi)的多集群進(jìn)行等比例擴(kuò)縮容。所有這些多集群編排能力都是基于騰訊云的 Clusternet 開源項目來建設(shè)。
進(jìn)一步提升資源利用率，難度也不斷加大
在過去三年多，騰訊統(tǒng)一了資源池，能夠在一個大的資源池中調(diào)度虛擬機、容器和函數(shù)，最大化地利用物理機的資源。業(yè)界很少有這么大規(guī)模的資源池，當(dāng)規(guī)模足夠大，底層的環(huán)境足夠復(fù)雜時，總會遇到一些別人遇不到的真實問題。
在不斷提升資源利用率時，你會發(fā)現(xiàn)，這其中大部分的時間都必須跟內(nèi)核打交道。
當(dāng)利用率提升了之后，整個節(jié)點里面的內(nèi)核資源搶占的問題會越來越嚴(yán)重。同一個節(jié)點上面部署了不同的業(yè)務(wù)，甚至上十個業(yè)務(wù)，這些業(yè)務(wù)都在一個節(jié)點上，利用率高的時候會出現(xiàn)網(wǎng)絡(luò)帶寬、內(nèi)核鎖等各種各樣的問題。每次遇到問題的時候，TKE 團(tuán)隊都需要和內(nèi)核團(tuán)隊一起去分析，經(jīng)常需要內(nèi)核團(tuán)隊經(jīng)常提供熱升級補丁，或者在下一個升級版本中去做優(yōu)化;然后為了減少“搶占”，也需要通過內(nèi)核優(yōu)化資源隔離能力;還需要完善內(nèi)核資源的監(jiān)控力度。比如說內(nèi)存的分配時間，CPU 在隊列里面的等待時間，這些很詳細(xì)的內(nèi)核穩(wěn)定性指標(biāo)，會由內(nèi)核暴露出來，給到容器。容器結(jié)合這些內(nèi)核的穩(wěn)定性指標(biāo)再去做調(diào)度決策，以提升整個節(jié)點的穩(wěn)定性。
在大規(guī)模資源池里追求極高利用率的場景下，還需要考慮幾十萬個節(jié)點的內(nèi)核版本的管理，也就是說一定要把這么多節(jié)點的內(nèi)核版本給收斂起來，不然太過零散，這些內(nèi)核問題永遠(yuǎn)都處理不完，一定要有一套自動化收斂節(jié)點內(nèi)核版本的機制。所以 TKE 團(tuán)隊做了一個基于業(yè)務(wù)無感知調(diào)度騰挪能力，去自動化升級節(jié)點內(nèi)核的系統(tǒng)，可以在業(yè)務(wù)低峰期的時候，比如每天凌晨的時候，自動化地分批次挑選最合適的節(jié)點，升級這個節(jié)點的內(nèi)核版本，逐步地、自動地將整個平臺的節(jié)點內(nèi)核版本收斂起來。
另外，因為騰訊是一家一二十年的老企業(yè)了，當(dāng)將所有資源都合并到一起后，就會存在有機型代次差異的不同服務(wù)器硬件，而不同代次的機型，算力是不一樣的，如果同一個工作負(fù)載的不同 Pod 位于不同代次的機器上，這就可能導(dǎo)致不同 Pod 的負(fù)載極其不均衡。為此，TKE 研發(fā)了基于機型的性能動態(tài)修改每一個 Pod 對應(yīng)的路由權(quán)重的能力。當(dāng)一個 Pod 底層用的是一些很老的機型的時候，會自動調(diào)低對應(yīng)的路由權(quán)重;當(dāng) Pod 底層的機型比較新的時候，對應(yīng)的權(quán)重會更大。通過這種方式，打平了不同 Pod 之間的負(fù)載，用戶看到的每一個 Pod 的負(fù)載都是均衡的，最終達(dá)到對業(yè)務(wù)屏蔽機型差異的目的。
另外，不同可用區(qū)域的資源余量也不一樣。為了解決資源問題，業(yè)務(wù)往往需要在不同可用區(qū)域之間來回騰挪。為了讓業(yè)務(wù)更加充分地利用不同可用區(qū)域的資源，能夠靈活地在不同可用區(qū)之間調(diào)度，甚至做到業(yè)務(wù)不感知可用區(qū)域的屬性。TKE 應(yīng)用管理平臺提供模糊可用區(qū)的能力，徹底屏蔽 K8s 節(jié)點、集群、可用區(qū)的概念，讓大部分業(yè)務(wù)完全不感知這些資源的屬性，充分利用不同可用區(qū)的資源，同時讓業(yè)務(wù)具備跨區(qū)域容災(zāi)能力。
云原生路線圖
如果要總結(jié)騰訊云原生的特色，那可能主要有三點。
第一點是超大規(guī)模，這種體量規(guī)模至少在國內(nèi)沒有第二家。第二點是業(yè)務(wù)場景極其豐富，包括社交、音視頻、游戲、支付、騰訊地圖等等業(yè)務(wù)場景。第三點，這些騰訊自研業(yè)務(wù)對穩(wěn)定性、容災(zāi)要求非常高。
王濤總結(jié)說，“我們做這個事情最大的壓力是要保證容器化之后業(yè)務(wù)的穩(wěn)定性，如果不小心把一個集群搞掛了，或者出現(xiàn)大面積的節(jié)點宕機，影響業(yè)務(wù)運行，這個后果就非常嚴(yán)重。也就是說我們從一開始就理解到業(yè)務(wù)對穩(wěn)定性要求極高，大家都是如履薄冰，做事情在細(xì)節(jié)上會考慮非常完善，因此 TKE 服務(wù)騰訊自研業(yè)務(wù)這么長時間，平臺沒有遇到過大的故障。”
如今 TKE 平臺在騰訊內(nèi)部已經(jīng)成功承載了數(shù)以億計的容器，支撐眾多海量業(yè)務(wù)平穩(wěn)運行，這個持續(xù)三年的改造項目，用鄒輝的話來講，它不是一錘子買賣，而是一個持續(xù)迭代、持續(xù)更新的過程。
騰訊根據(jù)自研業(yè)務(wù)以及目前一些外部企業(yè)使用 TKE 進(jìn)行云原生改造的經(jīng)驗，設(shè)計了一個五階段的路線圖，希望能夠給其他企業(yè)帶來參考。
