云計(ji)算的競爭曠(kuang)日持久(jiu)，表面看來(lai)格局(ju)初定(ding)，內里卻在醞(yun)釀巨變(bian)。
具(ju)有(you)先發(fa)優勢(shi)的玩(wan)家，好不(bu)(bu)容(rong)易取(qu)得(de)了看似不(bu)(bu)可撼動的地(di)位(wei)，不(bu)(bu)曾想(xiang)到有(you)朝一(yi)(yi)日會(hui)中(zhong)途被拉到同一(yi)(yi)起跑線，更換(huan)新的“CloudOS”重新出發(fa)。這個局面恐怕連 Kubernetes 早期創始人(ren)都會(hui)覺得(de)不(bu)(bu)可思議。他當初(chu)只是想(xiang)改變現狀，在亞馬遜的主導地(di)位(wei)下，讓(rang)谷歌取(qu)得(de)一(yi)(yi)戰之力。
2014 年(nian)，谷(gu)歌開源了(le) Kubernetes，紅帽、騰訊、阿里、華(hua)為(wei)等國(guo)內外一眾廠商開始力(li)出一處，共(gong)同推進 Kubernetes 的(de)采用。2017 年(nian)底(di)，就連亞馬遜也推出了(le) Kubernetes 產品，這也是 Kubernetes 成(cheng)為(wei)標準(zhun)化技術的(de)最(zui)大信號之(zhi)一。
這最終改變(bian)了整(zheng)個云計(ji)算(suan)。
大(da)家(jia)都開始基于(yu)(yu) Kubernetes 技(ji)術生(sheng)(sheng)態去構建公有云(yun)產(chan)(chan)品(pin)，基于(yu)(yu)統一(yi)的(de)(de)標準以避免“深度綁定”，但這也讓(rang)云(yun)原生(sheng)(sheng)行業嚴(yan)重同質化，因為(wei)各個云(yun)廠(chang)商(shang)所提(ti)供(gong)的(de)(de)功能(neng)和服務并沒有太大(da)的(de)(de)不(bu)同。對(dui)一(yi)些(xie)廠(chang)商(shang)來說，那(nei)些(xie)當年引以為(wei)豪的(de)(de)自研技(ji)術突(tu)破，那(nei)些(xie)樹立在公司(si)門口的(de)(de)紀念碑，那(nei)些(xie)專有性產(chan)(chan)品(pin)優勢，都被抹(mo)平(ping)，這是一(yi)件(jian)非常殘酷(ku)的(de)(de)事(shi)情。
同時這(zhe)又是一些公(gong)有云廠商重塑格局的(de)(de)機會。錨定 Kubernetes 進(jin)行(xing)云原(yuan)生(sheng)改造，相當(dang)于(yu)給公(gong)有云更換“技術底座”，并由(you)此(ci)構(gou)建出一些新(xin)的(de)(de)競爭(zheng)力，從而贏取更多用戶。
這場技術改造，難點在哪里?
對于騰訊來說，這不僅(jin)僅(jin)是一(yi)次技術“改造”，還兼帶著騰訊全(quan)體系“自研業(ye)務上(shang)云”的戰略任務。
在谷歌(ge) GKE 之后(hou)，騰(teng)訊(xun)(xun)云于 2017 年推出了 TKE。但騰(teng)訊(xun)(xun)云對外服務時，還是會面臨客戶的(de)質疑：“為什么騰(teng)訊(xun)(xun)自己的(de)業務沒有(you)使(shi)用騰(teng)訊(xun)(xun)公(gong)有(you)云，是不(bu)(bu)是不(bu)(bu)敢用?”
騰訊這次“云原生改造 + 上云”的價值就藏在客戶的拷問中。騰訊在這二十年里，發展出了包括社交、音視頻、游戲在內的多種業務，每種業務又都擁有海量的用戶。全面上云騰訊不是第一家，但騰訊是擁有最復雜的業務場景的一家，在這個過程中，需要結合業務制定各種各樣的技術方案，來滿足不同的業務訴求。可以理解為，每個業務的痛點都有局部最優解，而全面上云，則是在云上尋求通用最優解。如果這些痛點都能解決，那這樣的云服務是能有信心服務好客戶的。
要運(yun)行這么多(duo)業務(wu)(wu)，云原生底座也不能有短板，必須承載得了微信、QQ、音視頻、游戲(xi)等自研業務(wu)(wu)所有需(xu)求和(he)核心能力，并最(zui)終將這些業務(wu)(wu)的(de)技(ji)術積累和(he)技(ji)術優(you)勢反向復(fu)制到到公有云上，服務(wu)(wu)于外部用(yong)戶。
除此之外，云原生改造還對組織能力提出了考驗。
在移動互(hu)聯網時代，騰訊(xun)發展出了自己的(de)(de)技(ji)術(shu)(shu)哲學：每(mei)個(ge)(ge)業(ye)(ye)(ye)務(wu)都有自己的(de)(de)技(ji)術(shu)(shu)團隊，每(mei)個(ge)(ge)團隊都要打勝(sheng)仗(zhang)，這就要求“小、快、靈”，要有閉環。在自研業(ye)(ye)(ye)務(wu)上(shang)云之前，騰訊(xun)的(de)(de)每(mei)一個(ge)(ge)業(ye)(ye)(ye)務(wu)都有自己完(wan)整(zheng)的(de)(de)技(ji)術(shu)(shu)棧，內部業(ye)(ye)(ye)務(wu)在一定程度上(shang)形成了“部門墻”效應。并(bing)且因為技(ji)術(shu)(shu)棧不同，員(yuan)工從(cong)一個(ge)(ge)業(ye)(ye)(ye)務(wu)轉崗(gang)到另一個(ge)(ge)業(ye)(ye)(ye)務(wu)，需要重新(xin)學習一遍技(ji)術(shu)(shu)，這跟換公司沒(mei)什么區別。
根據(ju)財報數據(ju)，騰訊員(yuan)(yuan)(yuan)工已(yi)超十萬人，其中超過(guo) 7 成是技術人員(yuan)(yuan)(yuan)，這(zhe)是一(yi)(yi)次集體(ti)向云的(de)(de)(de)遷(qian)移(yi)，就像一(yi)(yi)次“搬(ban)家”，但又不僅僅是將行(xing)李打(da)包那么簡單，它(ta)是將具有(you)一(yi)(yi)二十年歷史的(de)(de)(de)不同特色(se)的(de)(de)(de)多個“大建筑”，制定(ding)“平移(yi)”方(fang)案遷(qian)移(yi)到(dao)新環境中繼續安然(ran)運行(xing)，難度可(ke)謂前(qian)所未有(you)的(de)(de)(de)高(gao)。考(kao)慮到(dao)花(hua)費的(de)(de)(de)時間(jian)、涉(she)及到(dao)的(de)(de)(de)人員(yuan)(yuan)(yuan)規模、技術深度，這(zhe)個項目可(ke)能(neng)是在世界范圍內也很(hen)難找到(dao)的(de)(de)(de)超級“軟件工程(cheng)”實踐(jian)。這(zhe)樣的(de)(de)(de)改造，過(guo)程(cheng)中既有(you)高(gao)層的(de)(de)(de)推進、動員(yuan)(yuan)(yuan)，也有(you)執行(xing)層的(de)(de)(de)博弈、妥協(xie)，最終(zhong)實現了用一(yi)(yi)個點調動全局，讓(rang)全公司(si)的(de)(de)(de)技術團隊(dui)得到(dao)了一(yi)(yi)次很(hen)好(hao)的(de)(de)(de)穿透對齊，讓(rang)分(fen)散的(de)(de)(de)技術能(neng)力得以統一(yi)(yi)。
有人說，評估騰訊云水平如何(he)，應該參看自研業務上云后的整體(ti)水平和運(yun)轉情況。
去年，騰(teng)訊自(zi)研(yan)業務(wu)初步完成了全部(bu)的(de)云(yun)(yun)原生技術改(gai)造，騰(teng)訊云(yun)(yun)將(jiang)所有(you)的(de)底層資源合并到一(yi)起(qi)進行統一(yi)管理(li)和調度，自(zi)研(yan)業務(wu)上(shang)云(yun)(yun)規模突破 5000 萬核(he)(he)，TKE 的(de)在離(li)線業務(wu)混部(bu)能力使服務(wu)器資源利用率(lv)從(cong) 30%提升至 65%，遠遠高于改(gai)造之(zhi)前。2020年，線上(shang)會(hui)議(yi)需(xu)求爆發(fa)，騰(teng)訊云(yun)(yun)組織(zhi)了幾(ji)十號人，花(hua)了8天(tian)緊急擴(kuo)容(rong)100萬核(he)(he)，創下(xia)了中(zhong)國云(yun)(yun)計算(suan)史上(shang)的(de)一(yi)個記錄。而全部(bu)上(shang)云(yun)(yun)之(zhi)后，放(fang)到現(xian)在這個階(jie)段(duan)，利用一(yi)鍵擴(kuo)縮(suo)容(rong)，騰(teng)訊會(hui)議(yi)再要去擴(kuo)容(rong) 100 萬核(he)(he)，那就是(shi)幾(ji)十分(fen)鐘的(de)事情。
所(suo)以，這次云(yun)原生改(gai)造的(de)好(hao)處顯(xian)而易(yi)見：對(dui)外，在垂直場景(jing)沉(chen)淀下(xia)來的(de)技術能力(li)，讓(rang)騰訊云(yun)原生獲得了(le)差異化的(de)產品能力(li)，能真正解決(jue)用戶在各種(zhong)場景(jing)下(xia)的(de)業務痛點;對(dui)內，讓(rang)騰訊在云(yun)端整體的(de)資源利(li)用率有了(le)一個大幅提升(sheng)，這本(ben)身就是巨大的(de)降本(ben)增效。
然而，這個過程卻(que)是(shi)經過了千辛萬苦(ku)。
“像下一盤棋”
2018 年，云原生行業(ye)發展趨勢初(chu)定(ding)。
隨(sui)著云原生(sheng)技(ji)(ji)術(shu)(shu)的興(xing)起，騰訊(xun)內部幾萬研發人(ren)員(yuan)(yuan)的技(ji)(ji)術(shu)(shu)焦(jiao)慮逐(zhu)漸(jian)加(jia)深(shen)。早期騰訊(xun)積累(lei)了(le)(le)大量的技(ji)(ji)術(shu)(shu)架構(gou)理念(nian)，技(ji)(ji)術(shu)(shu)人(ren)員(yuan)(yuan)有非常強烈的自豪感，但是(shi)(shi)越是(shi)(shi)成功(gong)的組織慣(guan)性就越大，騰訊(xun)內部很多技(ji)(ji)術(shu)(shu)理念(nian)和(he)(he)流程還(huan)停留在(zai)上(shang)一個時(shi)代。據稱，那(nei)時(shi)候騰訊(xun)內部討(tao)論平臺“樂(le)問”上(shang)充滿(man)了(le)(le)技(ji)(ji)術(shu)(shu)人(ren)員(yuan)(yuan)的吐槽(cao)和(he)(he)爭議。
除了“部門(men)墻”的(de)(de)存在(zai)(zai)(zai)，每個業務部門(men)為了應對突(tu)發的(de)(de)流量(liang)，在(zai)(zai)(zai)升級服務器資(zi)源時會留出資(zi)源緩沖區，當(dang)所(suo)(suo)有(you)的(de)(de)緩沖區疊加在(zai)(zai)(zai)一起，就形成了大量(liang)的(de)(de)閑(xian)置(zhi)資(zi)源浪(lang)費(fei)。所(suo)(suo)以，無論是(shi)從技術還是(shi)資(zi)源的(de)(de)角度來看，上云(yun)并進行(xing)統一的(de)(de)調度在(zai)(zai)(zai)當(dang)時已(yi)經(jing)是(shi)不得不做的(de)(de)事(shi)情。
2018 年(nian)底(di)騰訊開了一次高層決(jue)策(ce)會議(yi)，決(jue)定(ding)將公司內部(bu)所有(you)平臺合(he)到一起(qi)推行 K8s，開始進(jin)行徹底(di)的(de)技術更新換代。
這個事情(qing)一開始由(you)鄒輝領(ling)導的 TKE 團隊牽頭(tou)。TKE 團隊主要由(you)一批(pi)資(zi)深技術(shu)人員構成，成員基本都在 30 歲以上，資(zi)歷以 10 級(ji)、11 級(ji)為主，團隊對成員的技術(shu)能力(li)和業務(wu)理解能力(li)要求(qiu)很(hen)高(gao)。
決策已定(ding)，但(dan)是(shi)在執行(xing)過程(cheng)中，尤其是(shi) TKE 團隊(dui)，前半年時間(jian)并不是(shi)真正的(de)去做技術(shu)工(gong)作，而(er)是(shi)跟(gen)騰訊內(nei)部幾個事業群的(de)平臺技術(shu)團隊(dui)去聊需(xu)求聊具體(ti)的(de)改造方(fang)案，他們發現還是(shi)存在很大的(de)技術(shu)阻力。
騰(teng)訊(xun)云(yun)(yun)事業部(bu)門在 2016 年(nian)下半年(nian)的(de)時候就啟動(dong)基(ji)于 K8s 的(de) TKE 項目(mu)，但騰(teng)訊(xun)內部(bu)不同 BG 存(cun)在不同的(de)路(lu)線，有(you)(you)的(de)基(ji)于 Docker，有(you)(you)的(de)基(ji)于 Mesos。現在要將所有(you)(you)東西都統一到標準的(de)公有(you)(you)云(yun)(yun) TKE 上去，其實內部(bu)技術團隊難免會心(xin)生疑惑：你(ni)們是(shi)不是(shi)要過來(lai)搶我們的(de)活?
為了減輕這(zhe)些問題帶來的(de)阻力，當(dang)時騰(teng)訊(xun)沒有采取調整團(tuan)隊人員和效(xiao)仿建立技術(shu)中(zhong)臺的(de)方(fang)式(shi)(shi)，而(er)是制定了開(kai)源協(xie)(xie)同技術(shu)戰略，把公司內(nei)部所有做相似事情的(de)團(tuan)隊整合在一起，采取類似于外部開(kai)源運(yun)作的(de)方(fang)式(shi)(shi)協(xie)(xie)同工(gong)作。這(zhe)樣既解決了技術(shu)浪費(fei)的(de)問題，又可以去中(zhong)心(xin)化，保(bao)持快速響應，還能更好地滿足業務需求。騰(teng)訊(xun)內(nei)部把這(zhe)種模式(shi)(shi)稱為 OTeam。OTeam 掛在公司技術(shu)委員會下面(mian)。由這(zhe)七八個平臺組成的(de) K8s OTeam 就是一個典型(xing)的(de)例子，它是騰(teng)訊(xun)首(shou)批三個開(kai)源協(xie)(xie)同項目(mu)之(zhi)一。
在(zai)解決了技(ji)術團隊的顧(gu)慮之后(hou)，騰(teng)訊(xun)從(cong)高(gao)層開始推進(jin)，說服自研業務團隊上云(yun)，同時(shi)打通職級晉升(sheng)體系，通過(guo)設(she)置公司級的專(zhuan)項大獎、普(pu)及云(yun)原生(sheng)知識、改造進(jin)度榜單晾(liang)曬等，從(cong)多個(ge)方面入手提高(gao)大家積極性，依(yi)照三年規劃(hua)，有步驟地進(jin)行云(yun)原生(sheng)改造和(he)上云(yun)。
如何用好開源技術?
其實(shi)在上云決(jue)策制定之前，騰(teng)訊云已經(jing)花了(le)兩三年時間做了(le)一個 TKE“原型”，也踩過了(le)不少坑。
K8s 本身只(zhi)是一個主要(yao)做容器編排(pai)調度的(de)開源項(xiang)目，TKE 底層是基于標(biao)準的(de) K8s，再(zai)在(zai)上面進(jin)行產(chan)(chan)品(pin)化，將 K8s 和網(wang)絡(luo)能(neng)(neng)力(li)、存(cun)儲能(neng)(neng)力(li)、日志監(jian)(jian)控等能(neng)(neng)力(li)對應的(de)網(wang)絡(luo)產(chan)(chan)品(pin)、計算(suan)產(chan)(chan)品(pin)、日志產(chan)(chan)品(pin)、監(jian)(jian)控產(chan)(chan)品(pin)對接整(zheng)合，給用(yong)戶提供一個開箱即用(yong)的(de) K8s 產(chan)(chan)品(pin)，所以 TKE 對接了騰訊底層的(de)各種(zhong) IaaS 產(chan)(chan)品(pin)能(neng)(neng)力(li)。
2016 年騰訊開(kai)始做 TKE 的(de)時候，國(guo)內都還沒上(shang)(shang) K8s 服(fu)務(wu)，業(ye)界比較好的(de)產品設計也就是谷歌的(de) GKE，一切都是摸索著來。最(zui)(zui)開(kai)始，TKE 團隊試圖在云上(shang)(shang)提供(gong)一站式(shi)的(de) K8s 服(fu)務(wu)，將 K8s 的(de)概(gai)念進行了一些(xie)簡化(hua)，希望通過幫用(yong)戶降低(di)使用(yong) K8s 的(de)成本(ben)、讓用(yong)戶愿(yuan)意直接(jie)接(jie)入 K8s，但最(zui)(zui)終發現這條路線是錯的(de)。
他們發現(xian) K8s 不是(shi)(shi)(shi)直接面(mian)向(xiang)(xiang)終(zhong)端用戶(hu)的(de)，而是(shi)(shi)(shi)面(mian)向(xiang)(xiang)一(yi)(yi)個(ge)(ge)企業(ye)內的(de) Infra 平臺(tai)團(tuan)隊(dui)的(de)。應該由 Infra 團(tuan)隊(dui)基于 K8s 構建自(zi)己的(de) PaaS 平臺(tai)，提供(gong)給公司使用。“它是(shi)(shi)(shi)個(ge)(ge) Kernel，是(shi)(shi)(shi)云的(de)操作系統的(de)內核、不是(shi)(shi)(shi) PaaS。”于 2016 年(nian)加入 TKE 團(tuan)隊(dui)，一(yi)(yi)直負責(ze) K8s 產(chan)品化(hua)相關工(gong)作的(de)于廣游表(biao)示。“我(wo)們沒(mei)有(you)意(yi)識到(dao)這樣一(yi)(yi)個(ge)(ge)核心設(she)計的(de)本質。最(zui)開(kai)始，我(wo)們對它的(de)理解(jie)有(you)偏(pian)差，所以我(wo)們犯(fan)了一(yi)(yi)個(ge)(ge)錯(cuo)誤，走了一(yi)(yi)些彎路。早期的(de)時候(hou)為了面(mian)向(xiang)(xiang)業(ye)務有(you)一(yi)(yi)些改動(dong)，意(yi)識到(dao)錯(cuo)誤后，在 17 年(nian)底、18 年(nian)初的(de)時候(hou)就糾正了。后來才變成了我(wo)們現(xian)在 TKE 的(de)形態(tai)，我(wo)們也因此做了一(yi)(yi)次產(chan)品改名(ming)，從(cong) CCS 改名(ming)為 TKE(Tencent Kubernetes Engine)。”
到了 2018 年(nian)，騰訊(xun)啟(qi)動(dong)開源協同之(zhi)后(hou)，因為這七(qi)八個不(bu)(bu)同的(de)容器平(ping)臺團隊，各自(zi)都(dou)有各自(zi)的(de)優勢，如果(guo)要(yao)(yao)融成一個標準 K8s 技術(shu)，該怎么做?TKE 要(yao)(yao)么選擇(ze)都(dou)不(bu)(bu)接(jie)收、全(quan)部“作廢(fei)”重來(lai)(lai)，要(yao)(yao)么選擇(ze)將(jiang)所有的(de)歷史包(bao)袱都(dou)背起來(lai)(lai)。K8s OTeam 在一起討(tao)論之(zhi)后(hou)，選擇(ze)了后(hou)者(zhe)。
這(zhe)(zhe)也是(shi)為了上云而做出的妥協(xie)。整個(ge)(ge)公司“像(xiang)下(xia)(xia)(xia)一盤(pan)棋”，下(xia)(xia)(xia)棋是(shi)核心矛盾，往(wang) K8s 里貢獻不好維護的代(dai)碼(ma)是(shi)當(dang)時的次要矛盾。據鄒輝和于廣(guang)游(you)回憶(yi)，當(dang)時很(hen)快每一個(ge)(ge)團(tuan)隊(dui)都用上了 K8s，大家(jia)也都更(geng)加深刻地(di)理(li)解 K8s 了，理(li)解到(dao)往(wang) K8s 里面去改太多(duo)的邏輯，不是(shi)最(zui)優的方式。有(you)了這(zhe)(zhe)個(ge)(ge)共識之后，K8s OTeam 團(tuan)隊(dui)在不更(geng)改 K8s 主線(xian)代(dai)碼(ma)情況下(xia)(xia)(xia)，差不多(duo)用了一年時間，真的就把七(qi)八個(ge)(ge)平臺所有(you)的功能、核心技術特長(chang)全(quan)部(bu)融入到(dao)了 TKE 容器平臺上。
大家(jia)在(zai) K8s 基(ji)礎上(shang)去(qu)添(tian)加功(gong)能，且無(wu)需(xu)向用(yong)(yong)戶暴露 K8s 的(de)基(ji)本概念，那么“零 K8s 基(ji)礎”的(de)用(yong)(yong)戶也能快速(su)部署應(ying)用(yong)(yong)并管理其監控(kong)、日志、服務注冊在(zai)內的(de)整個生命周期(qi)。后來騰訊創建了(le)(le)一套(tao)應(ying)用(yong)(yong)模型 Tencent Application Definition(簡稱TAD)，直接使(shi)用(yong)(yong)應(ying)用(yong)(yong)管理平臺(tai)，用(yong)(yong)戶不需(xu)要(yao)去(qu)感知 K8s 細(xi)節(jie)，極大地降低了(le)(le)容器使(shi)用(yong)(yong)門檻。同(tong)時也引入了(le)(le)插(cha)(cha)(cha)件(jian)機制，復用(yong)(yong)了(le)(le) K8s 的(de)框架，可以(yi)像寫 K8s 插(cha)(cha)(cha)件(jian)一樣(yang)寫 TKE 插(cha)(cha)(cha)件(jian)，方便第(di)三方開(kai)發。
騰訊云原生底座的“養成”計劃
相比(bi)公有云外部客(ke)戶的業務(wu)，騰訊自研業務(wu)的體量更(geng)大，技術積累更(geng)深厚(hou)，測試(shi)標(biao)準也更(geng)全(quan)面和嚴苛(ke)，業務(wu)也千差萬別。
一開始，K8s 很(hen)多(duo)能(neng)力(li)不(bu)支持，業(ye)(ye)(ye)務(wu)很(hen)難平滑切(qie)(qie)換。在 2019 年之(zhi)前，大部分業(ye)(ye)(ye)務(wu)還是(shi)基于虛(xu)(xu)擬(ni)(ni)機(ji)(ji)的(de)(de)(de)方式去上云(yun)，因(yin)為自己(ji)的(de)(de)(de) IDC 物理機(ji)(ji)切(qie)(qie)到云(yun)上的(de)(de)(de)虛(xu)(xu)擬(ni)(ni)機(ji)(ji)之(zhi)后，這個(ge)過(guo)程業(ye)(ye)(ye)務(wu)基本上沒有感知(zhi)，整(zheng)個(ge)架構和代碼不(bu)需要(yao)任何的(de)(de)(de)改造。但是(shi)業(ye)(ye)(ye)務(wu)上虛(xu)(xu)擬(ni)(ni)機(ji)(ji)違(wei)背了上云(yun)本質訴(su)求，即(ji)希(xi)望利用(yong)云(yun)原生(sheng)的(de)(de)(de)快速彈性伸縮能(neng)力(li)，和統一資源池的(de)(de)(de)其他(ta)一些能(neng)力(li)去提升各個(ge)業(ye)(ye)(ye)務(wu)團隊的(de)(de)(de)研發效能(neng)，所以最(zui)終 TKE 團隊還是(shi)需要(yao)幫助業(ye)(ye)(ye)務(wu)從虛(xu)(xu)擬(ni)(ni)機(ji)(ji)切(qie)(qie)到容器化，并提供相應的(de)(de)(de)產品能(neng)力(li)。
TKE 平臺在初期選(xuan)擇的(de)更多還是一(yi)些無狀態的(de)業務，先讓這些無狀態的(de)業務能(neng)夠快速(su)搬(ban)到云(yun)上完成(cheng)改造。團(tuan)隊選(xuan)擇了一(yi)些平臺的(de)核心能(neng)力去解決業務痛點，比如說“發布”的(de)問題。
在公有(you)云場景下(xia)大家使用(yong)的(de)(de)(de)是(shi) K8s 基(ji)本(ben)的(de)(de)(de)發(fa)布(bu)(bu)能(neng)力(li)，比如基(ji)于滾動的(de)(de)(de)發(fa)布(bu)(bu)。滾動發(fa)布(bu)(bu)過程(cheng)(cheng)可(ke)控(kong)性(xing)很(hen)差，遇到了(le)問題后回滾，整個發(fa)布(bu)(bu)就會(hui)中(zhong)斷。騰(teng)訊自研業(ye)務(wu)(wu)需(xu)(xu)要(yao)滿(man)足灰度發(fa)布(bu)(bu)的(de)(de)(de)要(yao)求(qiu)(qiu)，灰度發(fa)布(bu)(bu)對業(ye)務(wu)(wu)來(lai)說也是(shi)非(fei)常(chang)關鍵的(de)(de)(de)一(yi)(yi)項能(neng)力(li)。為了(le)保(bao)證服務(wu)(wu)的(de)(de)(de)質量，業(ye)務(wu)(wu)團(tuan)隊要(yao)求(qiu)(qiu)能(neng)夠非(fei)常(chang)精準地控(kong)制發(fa)布(bu)(bu)頻率、節奏和容錯，做到發(fa)布(bu)(bu)過程(cheng)(cheng)一(yi)(yi)切盡在掌控(kong)之中(zhong)。針對這樣(yang)的(de)(de)(de)需(xu)(xu)求(qiu)(qiu)，TKE 在自定(ding)(ding)義工作負載基(ji)礎(chu)之上(shang)發(fa)布(bu)(bu)了(le)一(yi)(yi)套灰度發(fa)布(bu)(bu)策略，業(ye)務(wu)(wu)可(ke)以指(zhi)定(ding)(ding)要(yao)發(fa)布(bu)(bu)的(de)(de)(de) Pod，可(ke)以按照一(yi)(yi)定(ding)(ding)的(de)(de)(de)百分比進行發(fa)布(bu)(bu)，也可(ke)以設置升級失敗的(de)(de)(de)比例來(lai)實現暫停(ting)或(huo)回滾。
同時 TKE 也給業務(wu)提(ti)供了(le)一(yi)些虛(xu)擬(ni)(ni)機提(ti)供不了(le)的(de)(de)能力，比如(ru)(ru)動(dong)態路(lu)由(you)能力，在容器銷(xiao)毀(hui)時，平(ping)臺會將(jiang)對應路(lu)由(you)去掉，在容器起(qi)來后，平(ping)臺會自動(dong)將(jiang)容器加(jia)到路(lu)由(you)中。使用虛(xu)擬(ni)(ni)機，業務(wu)需要自己去配(pei)置(zhi)，使用容器之后，就不需要去管理業務(wu)的(de)(de)路(lu)由(you)了(le)，通過 K8s Operater 的(de)(de)機制已經實現自動(dong)化(hua)。如(ru)(ru)此一(yi)來，大家(jia)開始初步感(gan)知(zhi)到容器帶來的(de)(de)效率價值。
另外一(yi)個(ge)好處則是彈性伸縮和健康感知。之(zhi)前使用(yong)虛(xu)擬(ni)機(ji)部(bu)署(shu)業(ye)務(wu)(wu)時，需(xu)要用(yong)戶先購(gou)買虛(xu)擬(ni)機(ji)，再在虛(xu)擬(ni)機(ji)里去(qu)部(bu)署(shu)業(ye)務(wu)(wu)的(de)包(bao)，再確(que)認業(ye)務(wu)(wu)進(jin)程(cheng)健康拉起運(yun)行(xing)，最后對路(lu)由進(jin)行(xing)管理......這個(ge)流(liu)程(cheng)在接入容器(qi)之(zhi)后可(ke)以大幅簡化，通過配置自(zi)動擴縮容的(de)能力，或者手(shou)動觸發，修(xiu)改副本數后，后面(mian)所(suo)有的(de)流(liu)程(cheng)都是自(zi)動化的(de)，可(ke)以做到(dao)秒級創建一(yi)批 Pod、自(zi)動感知實例(li)健康狀(zhuang)態并添加到(dao)服務(wu)(wu)路(lu)由里去(qu)，業(ye)務(wu)(wu)擴容非(fei)常絲滑。
還(huan)有就是成本(ben)上的(de)優(you)勢，尤其是這幾年，所有業(ye)務成本(ben)壓力(li)(li)都比(bi)(bi)較大。容器在的(de)優(you)勢是按(an)量計費(fei)，Pod 銷毀了就不(bu)收費(fei)了，計費(fei)粒(li)(li)度是秒(miao)級的(de)，但(dan)虛擬機不(bu)一樣，它的(de)生命(ming)周(zhou)期更重一些，彈性能力(li)(li)也比(bi)(bi)容器差，計費(fei)粒(li)(li)度也更粗。
此外，騰訊(xun)垂直業務場景也會給(gei)容器(qi)平臺提(ti)出不一樣(yang)的需求(qiu)，為(wei)了滿足這些(xie)需求(qiu)，TKE 反之也給(gei)自(zi)己(ji)帶(dai)來了差異化能力，這些(xie)最終都轉變為(wei)了騰訊(xun)云原生產品的競爭力。
從垂直場景走出來的通用產品競爭力
從 2020 年(nian)下半年(nian)開(kai)始，騰訊游戲(xi)(xi)共有(you)十多款產(chan)品陸續推動云原生改造，轉向微服(fu)務架構。游戲(xi)(xi)是騰訊所有(you)業務里(li)軟件結構比(bi)較特殊的(de)一(yi)個，游戲(xi)(xi)服(fu)務的(de)鏡像(xiang)一(yi)般比(bi)較大(da)，有(you)的(de)甚至達到十幾 GB。而我們每啟(qi)動或更新一(yi)個容(rong)器，就需要將對應的(de)應用程序從遠(yuan)端拉到本地的(de)機器上啟(qi)動，這么大(da)的(de)鏡像(xiang)，在部署(shu)的(de)時(shi)候，并發對網絡要求很高，源端就成了一(yi)個瓶(ping)頸。
為了解決這個問題(ti)，Oteam 團隊在 會議上討論(lun)了很多次，商量出了一套“鏡像分(fen)發系(xi)統(tong)”的(de)解決方法，類似 P2P 下載網狀結構(gou)，避(bi)免源(yuan)端成為瓶頸(jing)點。據騰訊(xun)游戲介(jie)紹：“云原生架構(gou)里基于容器的(de)快速擴縮(suo)容，是以分(fen)鐘級、秒級來實(shi)現的(de)，以前我們只能以十分(fen)鐘為單位。”
提高鏡像分發的效率，不僅僅是有益于游(you)戲場(chang)(chang)景(jing)。在一些 AI 訓(xun)練場(chang)(chang)景(jing)中，鏡像甚至更大，幾十 GB 也不少(shao)見，如果是需要(yao)發布(bu)成(cheng)千上萬個 Pod，那就需要(yao)幾十分鐘，甚至更長時間，所以(yi)現在這種解(jie)決(jue)方案(an)同(tong)樣也可(ke)以(yi)適(shi)用于大規(gui)模訓(xun)練場(chang)(chang)景(jing)。
而在(zai)騰訊會議(yi)以及其他社交場景中，也有一(yi)些特殊要(yao)求，這種服(fu)(fu)務往(wang)往(wang)含有大量的(de)會話信(xin)息(xi)，很(hen)多(duo)是(shi)長(chang)連(lian)接，有些業務還會大量使用(yong)共享(xiang)內存，這些都屬于有狀態(tai)的(de)服(fu)(fu)務。
無狀(zhuang)態(tai)的(de)容(rong)器擴縮(suo)容(rong)相(xiang)對簡單，但有狀(zhuang)態(tai)的(de)服務要去享(xiang)受容(rong)器化的(de)灰度(du)(du)發(fa)布、彈性伸縮(suo)能(neng)(neng)力(li)，難度(du)(du)很大，需(xu)要對業務架(jia)構進(jin)行大量改造。因為業務不可能(neng)(neng)在短(duan)時間內(nei)做(zuo)存算分(fen)離，把存儲(chu)層(ceng)下沉、上層(ceng)邏(luo)輯層(ceng)做(zuo)成一個(ge)無狀(zhuang)態(tai)的(de)服務。所以(yi)容(rong)器就必須扛(kang)起這個(ge)責任，基于(yu)業務的(de)這些特殊需(xu)求，在容(rong)器層(ceng)適配有狀(zhuang)態(tai)服務。
在有狀態的服務中(zhong)(zhong)，如果(guo)在(zai)升(sheng)級(ji)(ji)過(guo)(guo)程中(zhong)(zhong)對(dui)應(ying)容器(qi)的(de)中(zhong)(zhong)斷(duan)(duan)時(shi)間(jian)達到秒(miao)級(ji)(ji)，用戶通話就(jiu)(jiu)會出現延遲和(he)卡頓，所以在(zai)升(sheng)級(ji)(ji)過(guo)(guo)程中(zhong)(zhong)就(jiu)(jiu)要保證(zheng) Pod 容器(qi)的(de)中(zhong)(zhong)斷(duan)(duan)時(shi)間(jian)控(kong)(kong)制在(zai)一(yi)秒(miao)以內。TKE 團隊實現了一(yi)種(zhong)自定義工作負載，將新(xin)版本業務鏡(jing)像提(ti)前(qian)下載到 Pod 里(li)，通過(guo)(guo)文(wen)件鎖和(he)容器(qi)狀態探測機制來控(kong)(kong)制老版本和(he)新(xin)版本之間(jian)的(de)快速切換，將升(sheng)級(ji)(ji)的(de)中(zhong)(zhong)斷(duan)(duan)時(shi)間(jian)控(kong)(kong)制在(zai)毫秒(miao)級(ji)(ji)別。
另一個不得不提(ti)的是原(yuan)(yuan)地(di)升(sheng)級的能力，比如(ru)(ru)說(shuo)容(rong)器(qi)擴(kuo)(kuo)容(rong)的時候，不是通過(guo)銷毀重建的方法擴(kuo)(kuo)容(rong)，而是通過(guo)原(yuan)(yuan)地(di)無(wu)(wu)感(gan)知(zhi)(zhi)的提(ti)升(sheng)擴(kuo)(kuo)容(rong)。比如(ru)(ru)一般公有云(yun)對(dui)(dui) 4 核(he) 8G 的容(rong)器(qi)進(jin)行擴(kuo)(kuo)容(rong)，會將其銷毀重新(xin)創一個 8 核(he) 16G 的，這種(zhong)對(dui)(dui)業務是有感(gan)知(zhi)(zhi)的。TKE 實現了(le)更快速的原(yuan)(yuan)地(di)升(sheng)配，可以將 4 核(he) 8G 的容(rong)器(qi)原(yuan)(yuan)地(di)變成 8 核(he) 16G，但業務對(dui)(dui)此(ci)是無(wu)(wu)感(gan)的，除(chu)此(ci)之外(wai)，還(huan)支持分批原(yuan)(yuan)地(di)更新(xin) Probe、Image 等能力。
另外，這(zhe)幾年騰(teng)訊會議(yi)經常遇(yu)到用(yong)(yong)戶(hu)(hu)人(ren)數突然暴增的情況，比(bi)如每年 9 月 1 號秋季開(kai)學的時候，騰(teng)訊會議(yi)的用(yong)(yong)戶(hu)(hu)量就會漲好幾倍。騰(teng)訊會議(yi)應用(yong)(yong)程序內部有大(da)大(da)小(xiao)小(xiao)幾百個(ge)模塊，一個(ge)應用(yong)(yong)下面可能(neng)就包含幾十(shi)個(ge)模塊，運維人(ren)員(yuan)需要(yao)做大(da)量的緊急(ji)擴(kuo)充容(rong)，手動完成一次對(dui)應用(yong)(yong)的擴(kuo)縮容(rong)，針(zhen)對(dui)這(zhe)幾十(shi)個(ge)模塊進(jin)行操作，可能(neng)要(yao)投入(ru)很(hen)多的人(ren)力(li)，需要(yao)很(hen)長的時間(jian)。
為了減輕運維負擔，TKE 團隊實現了基于 PCU，即同時最大在線人數，這么一個指標去做一鍵擴縮容的功能。比如說現在騰訊會議在第一天的同時最大在線人數 PCU 是一千萬人，以此預測，第二天可能就是兩千萬人，那意味著騰訊會議的上下游整個鏈路基本上要擴容一倍。之前運維要去做這個事情，得去找整個騰訊會議幾萬個 Workload，然后對每個 Workload 將副本數擴一倍。為了提升這里的效率，騰訊自研了云原生全局一鍵擴縮容的產品能力，將整個騰訊(xun)會議關(guan)聯的這些 Workload 構(gou)建成一個或者若干(gan)個業務拓撲，同(tong)一個業務拓撲內的 Workloads 支(zhi)持等比例的一鍵(jian)擴(kuo)縮容。
“我(wo)記得(de)在(zai)早期的時(shi)候，騰(teng)訊會議(yi)這(zhe)(zhe)幾百個(ge)模(mo)塊，擴(kuo)容幾十萬核(he)可能(neng)要(yao)花個(ge)近半天時(shi)間，但我(wo)們把這(zhe)(zhe)個(ge)能(neng)力實現后，當大(da)家再面對這(zhe)(zhe)種擴(kuo)縮容場景時(shi)，20 分鐘(zhong)左右就能(neng)完成這(zhe)(zhe)幾百個(ge)模(mo)塊的共(gong)計(ji)幾十萬核(he)的擴(kuo)縮容。”
這(zhe)種(zhong)基(ji)于業(ye)務(wu)拓(tuo)(tuo)撲(pu)(pu)的(de)全局(ju)擴(kuo)縮容(rong)能力(li)其實是一(yi)(yi)種(zhong)普適性(xing)的(de)大規模業(ye)務(wu)訴求，很多業(ye)務(wu)做活動都會基(ji)于一(yi)(yi)個(ge)北(bei)極星(xing)指標來進行容(rong)量(liang)評估。針對(dui)這(zhe)個(ge)通用(yong)的(de)需求，TKE 團隊(dui)將之提煉成一(yi)(yi)個(ge)通用(yong)的(de)產品(pin)能力(li)，在 TKE 平臺上形(xing)成了一(yi)(yi)個(ge)全局(ju)的(de)(跨地域(yu)、跨集(ji)群)、基(ji)于業(ye)務(wu)拓(tuo)(tuo)撲(pu)(pu)的(de)一(yi)(yi)鍵擴(kuo)縮容(rong)的(de)產品(pin)功能。
通過上(shang)面(mian)這(zhe)(zhe)些(xie)(xie)一個(ge)個(ge)的貼近(jin)真實業務(wu)(wu)的“小細節”，我(wo)們(men)(men)可以(yi)看(kan)出騰訊(xun)做(zuo)云原生(sheng)的思路是(shi)希(xi)望讓用戶的付出和痛苦最(zui)小、收益最(zui)大，盡量減少業務(wu)(wu)架(jia)構的改(gai)造，減少運(yun)維(wei)的壓力。而且這(zhe)(zhe)些(xie)(xie)動態路由、無感升級(ji)等(deng)功能(neng)(neng)(neng)，王濤表(biao)示不僅僅是(shi)內部(bu)自研業務(wu)(wu)需(xu)(xu)要(yao)，“我(wo)發現很多外(wai)(wai)部(bu)客戶平時(shi)都有類似的這(zhe)(zhe)種需(xu)(xu)求，他們(men)(men)也(ye)急(ji)需(xu)(xu)要(yao)這(zhe)(zhe)樣的一些(xie)(xie)產(chan)品能(neng)(neng)(neng)力，這(zhe)(zhe)也(ye)推動著(zhu)我(wo)們(men)(men)將這(zhe)(zhe)些(xie)(xie)能(neng)(neng)(neng)力從內部(bu)推到公有云上(shang)去，提供(gong)給(gei)外(wai)(wai)部(bu)客戶。所以(yi)，我(wo)們(men)(men)在騰訊(xun)自研業務(wu)(wu)上(shang)打磨的這(zhe)(zhe)些(xie)(xie)能(neng)(neng)(neng)力也(ye)變(bian)成(cheng)了(le)騰訊(xun)云產(chan)品的一個(ge)優勢(shi)。”
深水區的那些痛
騰訊花了一(yi)年半(ban)的(de)時間(jian)，將無狀態業(ye)(ye)務(wu)(wu)搬到(dao)了云(yun)原(yuan)生(sheng)平(ping)臺，幾乎(hu)把能(neng)踩的(de)坑都踩了一(yi)遍，為后續(xu)其他業(ye)(ye)務(wu)(wu)上(shang)云(yun)鋪平(ping)了道路。這也證明(ming)了上(shang)云(yun)是可行(xing)的(de)，給了業(ye)(ye)務(wu)(wu)團隊(dui)更(geng)大的(de)信心，后面就有更(geng)多業(ye)(ye)務(wu)(wu)滾雪球(qiu)式地自發(fa)接入了。到(dao)了 2020 年底，上(shang)云(yun)的(de)自研(yan)業(ye)(ye)務(wu)(wu)已經達到(dao)了三(san)四(si)百萬(wan)核心的(de)規模(mo)，平(ping)臺也運行(xing)得非常穩定(ding)，所以 TKE 團隊(dui)開始通過提升資源(yuan)利用(yong)率、降低成(cheng)本，來證明(ming)云(yun)原(yuan)生(sheng)確(que)實能(neng)夠給業(ye)(ye)務(wu)(wu)和公司帶來很多實實在(zai)在(zai)的(de)好處。
經過(guo) 2021 年(nian)整(zheng)整(zheng)一年(nian)時間，通過(guo)一系列的技術(shu)手段，團(tuan)隊把一些混部集群(qun)的利用率(lv)提升到了 65%。
同時在一些業務層面，一些有狀態的業務，比如說(shuo)像(xiang) Redis 數據(ju)庫、中間(jian)件(jian)(jian)、一(yi)些大數據(ju)的套件(jian)(jian)，也(ye)做了(le)原生(sheng)改造，逐步(bu)搬到了(le)整個(ge)云(yun)(yun)原生(sheng)平(ping)臺(tai)上來，騰訊內部(bu)(bu)數據(ju)庫團隊進一(yi)步(bu)開發了(le)“云(yun)(yun)巢”云(yun)(yun)原生(sheng)有狀態(tai)服務平(ping)臺(tai)。這(zhe)個(ge)階(jie)段差不多也(ye)用了(le)一(yi)年時間(jian)，最終到 2022 年，也(ye)就是到去(qu)年為(wei)止，整個(ge)騰訊內部(bu)(bu)的資源業務基本上完(wan)成(cheng)了(le)上云(yun)(yun)，整體(ti)資源達到了(le) 5000 萬核，3 年累(lei)計節省(sheng) 30 億。騰訊云(yun)(yun)包含(han)了(le)混部(bu)(bu)解(jie)決方案的開源項目 Crane 也(ye)經過(guo)認(ren)證，成(cheng)為(wei) FinOps 全球首個(ge)認(ren)證降本增效開源方案。
在這個過程中，TKE 團隊在調度層面做了大量的工作。
在統(tong)一資(zi)源池中(zhong)，資(zi)源分散(san)在不(bu)同(tong)(tong)的 K8s 集群(qun)里，不(bu)同(tong)(tong) K8s 集群(qun)的資(zi)源利用率(lv)參差不(bu)齊;資(zi)源需要在不(bu)同(tong)(tong) K8s 集群(qun)之間流轉，將閑置(zhi)機器騰(teng)挪到(dao)繁(fan)忙的集群(qun)中(zhong)，讓每個集群(qun)的資(zi)源率(lv)都非常高(gao)，這(zhe)個工(gong)作是特別困難的。
最開始，TKE 團(tuan)隊嘗試優(you)化每一個(ge)集(ji)群(qun)(qun)的(de)(de)資源利(li)(li)用率，同時(shi)(shi)通過在離(li)線(xian)混部，把每一個(ge)集(ji)群(qun)(qun)中的(de)(de)額外的(de)(de)資源抽離(li)到(dao)另外的(de)(de)算(suan)力平(ping)臺中，進行統一的(de)(de)調(diao)度。這(zhe)雖然(ran)緩解了很多問(wen)(wen)題(ti)，但隨著(zhu)利(li)(li)用率越來越高，干擾的(de)(de)問(wen)(wen)題(ti)還是會存在。為了解決(jue)這(zhe)個(ge)問(wen)(wen)題(ti)，TKE 團(tuan)隊引(yin)入了新(xin)的(de)(de)統一調(diao)度方(fang)案，讓 K8s 不再負(fu)責調(diao)度，只(zhi)負(fu)責 Pod 的(de)(de)管理(li)，真正去分配資源的(de)(de)時(shi)(shi)候，是將請求給(gei)到(dao)了 Serverless 調(diao)度器進行統一調(diao)度，解決(jue)資源使用不均的(de)(de)問(wen)(wen)題(ti)。
同時，因為 K8s 自帶的(de)(de)原(yuan)生 HPA 控(kong)制器(qi)(qi)，在這(zhe)(zhe)種(zhong)大(da)規模場景下，擴(kuo)縮容(rong)會(hui)有(you)非常大(da)的(de)(de)性(xing)能問題，比如(ru)在業務流量的(de)(de)洪峰來(lai)臨時來(lai)不及擴(kuo)容(rong)，或(huo)流量出現(xian)抖(dou)動。所以騰(teng)訊將原(yuan)來(lai)的(de)(de)控(kong)制器(qi)(qi)從 K8s 里剝離出來(lai)，單獨部署，這(zhe)(zhe)樣就(jiu)可以進行單獨的(de)(de)一(yi)些(xie)管理，如(ru)高可用(yong)、容(rong)災(zai)等，同時對控(kong)制器(qi)(qi)里的(de)(de)內部實現(xian)邏輯做(zuo)一(yi)些(xie)性(xing)能優(you)化，來(lai)滿(man)足這(zhe)(zhe)種(zhong)大(da)規模場景下業務需要的(de)(de)秒級的(de)(de)彈性(xing)擴(kuo)縮容(rong)的(de)(de)能力。
沉淀多集群管理能力
前兩三(san)年(nian)云原生行業都在(zai)“卷”單(dan)集(ji)(ji)群(qun)(qun)規模(mo)，通過優化 ETCD、API Server、Controller 調度(du)器的(de)性能，將單(dan)集(ji)(ji)群(qun)(qun)的(de)節點(dian)規模(mo)做(zuo)大，達到上萬節點(dian)。但最(zui)后瓶頸還(huan)是很明顯，做(zuo)到 5K 個節點(dian)集(ji)(ji)群(qun)(qun)跟一萬節點(dian)的(de)集(ji)(ji)群(qun)(qun)，本質上沒有帶來(lai)很大的(de)業務價值，反而一旦單(dan)集(ji)(ji)群(qun)(qun)出現故(gu)障，爆炸半(ban)徑會很大。
所(suo)以(yi)，在(zai)騰訊看來，一(yi)味地(di)去突破單集群性能不是一(yi)個正確(que)的技(ji)術(shu)路線(xian)。
最近整個(ge)社區，包括騰訊主要投(tou)入做多(duo)集群(qun)的(de)管(guan)理。單集群(qun)做得更小，比如說兩千個(ge)節(jie)點，甚至幾百個(ge)節(jie)點就(jiu)行;但(dan)是讓更多(duo)的(de)集群(qun)組合在一(yi)起，通(tong)過多(duo)集群(qun)的(de)調度管(guan)理，讓它看起來(lai)像(xiang)一(yi)個(ge)集群(qun)，通(tong)過這種方式去擴展整個(ge)底層資源池的(de)規模。
TKE 沉淀了各種(zhong)多集(ji)(ji)群(qun)管理(li)的(de)能力(li)，讓上層的(de)這種(zhong)多集(ji)(ji)群(qun)管理(li)能夠(gou)去(qu)統一調度管理(li)跨(kua)分(fen)區、跨(kua)地域的(de)多集(ji)(ji)群(qun)資(zi)源(yuan)。在此基礎上，再重點(dian)解決了從面向(xiang)集(ji)(ji)群(qun)到(dao)面向(xiang)應用的(de)調度編排問題。
這在部(bu)署全球化的業務時非常有(you)幫助。原生 K8s 是面向(xiang)集群的一套(tao)編排調度(du)系統，用(yong)戶感知的是集群里面的 K8s 對(dui)(dui)象，沒有(you)提供基(ji)于可用(yong)區容量感知調度(du)、副(fu)本(ben)分(fen)(fen)配策略決策這些調度(du)能力。比如一個(ge)業務全網有(you)一萬(wan)個(ge)工作負(fu)載、五萬(wan)個(ge) Pod，分(fen)(fen)布在全球十七個(ge)地域，共(gong)八十多個(ge)集群。如果要(yao)對(dui)(dui)這個(ge)業務做一次全網變(bian)更，按照以前面向(xiang)集群的方式(shi)效率非常低(di)。
所以(yi)騰(teng)訊(xun)(xun)云原生團隊抽(chou)象出了(le)(le)面(mian)(mian)向應(ying)用(yong)(yong)的能(neng)力(li)(li)，對跨集群應(ying)用(yong)(yong)的統一變更，提(ti)供了(le)(le)一個應(ying)用(yong)(yong)管理平臺，用(yong)(yong)統一的看(kan)板(ban)跟蹤發布是(shi)(shi)(shi)否正常(chang)。業務部署后(hou)還(huan)要能(neng)從視圖看(kan)到部署的容(rong)(rong)災(zai)是(shi)(shi)(shi)不是(shi)(shi)(shi)合理的，所以(yi)要有多地域(yu)的容(rong)(rong)災(zai)檢(jian)測。平臺也可(ke)(ke)以(yi)根據用(yong)(yong)戶定義好容(rong)(rong)災(zai)部署策(ce)略進行巡檢(jian)，出了(le)(le)異常(chang)可(ke)(ke)以(yi)自動(dong)告警。在面(mian)(mian)向全(quan)球化上，用(yong)(yong)戶還(huan)可(ke)(ke)以(yi)利(li)用(yong)(yong)全(quan)局一鍵擴縮容(rong)(rong)能(neng)力(li)(li)，對海(hai)外和(he)國內的多集群進行等比例擴縮容(rong)(rong)。所有這些(xie)多集群編排(pai)能(neng)力(li)(li)都是(shi)(shi)(shi)基于騰(teng)訊(xun)(xun)云的 Clusternet 開(kai)源項(xiang)目來建設。
進一步提升資源利用率，難度也不斷加大
在過去三年(nian)多，騰(teng)訊統一(yi)(yi)了資(zi)源池(chi)，能夠在一(yi)(yi)個大(da)(da)的資(zi)源池(chi)中調度(du)虛擬機、容器(qi)和函數，最大(da)(da)化地利用物(wu)理機的資(zi)源。業界(jie)很(hen)少有這么大(da)(da)規(gui)模(mo)的資(zi)源池(chi)，當規(gui)模(mo)足夠大(da)(da)，底層的環境足夠復(fu)雜時，總(zong)會(hui)遇(yu)到一(yi)(yi)些別人(ren)遇(yu)不到的真(zhen)實問題。
在(zai)不斷提(ti)升資源利用率時，你會發現，這其(qi)中大部分的時間都必須跟內核打交道。
當利(li)用率提(ti)(ti)升了之后，整個(ge)(ge)節(jie)(jie)點(dian)(dian)(dian)里(li)面(mian)(mian)的(de)內(nei)(nei)(nei)核(he)(he)資源(yuan)搶占的(de)問(wen)題會(hui)越來(lai)越嚴(yan)重。同一(yi)(yi)(yi)個(ge)(ge)節(jie)(jie)點(dian)(dian)(dian)上(shang)面(mian)(mian)部(bu)署了不同的(de)業務(wu)(wu)，甚至上(shang)十個(ge)(ge)業務(wu)(wu)，這(zhe)(zhe)些業務(wu)(wu)都(dou)在一(yi)(yi)(yi)個(ge)(ge)節(jie)(jie)點(dian)(dian)(dian)上(shang)，利(li)用率高的(de)時(shi)候(hou)會(hui)出現網絡帶寬、內(nei)(nei)(nei)核(he)(he)鎖等(deng)各種(zhong)各樣(yang)的(de)問(wen)題。每次(ci)遇(yu)到(dao)問(wen)題的(de)時(shi)候(hou)，TKE 團(tuan)隊都(dou)需(xu)(xu)要和內(nei)(nei)(nei)核(he)(he)團(tuan)隊一(yi)(yi)(yi)起去分析，經常需(xu)(xu)要內(nei)(nei)(nei)核(he)(he)團(tuan)隊經常提(ti)(ti)供熱(re)升級補丁，或者(zhe)在下一(yi)(yi)(yi)個(ge)(ge)升級版本(ben)中去做優化;然后為了減少“搶占”，也需(xu)(xu)要通過內(nei)(nei)(nei)核(he)(he)優化資源(yuan)隔離能力;還(huan)需(xu)(xu)要完善內(nei)(nei)(nei)核(he)(he)資源(yuan)的(de)監控(kong)力度。比(bi)如說內(nei)(nei)(nei)存的(de)分配時(shi)間(jian)(jian)，CPU 在隊列里(li)面(mian)(mian)的(de)等(deng)待時(shi)間(jian)(jian)，這(zhe)(zhe)些很詳細(xi)的(de)內(nei)(nei)(nei)核(he)(he)穩定(ding)性指標(biao)，會(hui)由內(nei)(nei)(nei)核(he)(he)暴露出來(lai)，給到(dao)容(rong)器。容(rong)器結合這(zhe)(zhe)些內(nei)(nei)(nei)核(he)(he)的(de)穩定(ding)性指標(biao)再去做調度決策，以(yi)提(ti)(ti)升整個(ge)(ge)節(jie)(jie)點(dian)(dian)(dian)的(de)穩定(ding)性。
在大規(gui)模資源池(chi)里追求極高利用率的(de)(de)(de)場(chang)景(jing)下，還需要考慮幾十萬個(ge)節(jie)(jie)點(dian)(dian)的(de)(de)(de)內(nei)核(he)(he)版(ban)本的(de)(de)(de)管(guan)理，也就是說一(yi)(yi)定(ding)要把這么多(duo)節(jie)(jie)點(dian)(dian)的(de)(de)(de)內(nei)核(he)(he)版(ban)本給收斂起(qi)來，不然太過零散，這些內(nei)核(he)(he)問題(ti)永遠都處理不完(wan)，一(yi)(yi)定(ding)要有(you)一(yi)(yi)套自動化收斂節(jie)(jie)點(dian)(dian)內(nei)核(he)(he)版(ban)本的(de)(de)(de)機制(zhi)。所以 TKE 團隊做了(le)一(yi)(yi)個(ge)基于業務無(wu)感知調度騰挪能力，去自動化升級節(jie)(jie)點(dian)(dian)內(nei)核(he)(he)的(de)(de)(de)系統(tong)，可以在業務低峰(feng)期的(de)(de)(de)時(shi)候(hou)(hou)，比如每(mei)天凌晨(chen)的(de)(de)(de)時(shi)候(hou)(hou)，自動化地(di)分批次挑選最合(he)適的(de)(de)(de)節(jie)(jie)點(dian)(dian)，升級這個(ge)節(jie)(jie)點(dian)(dian)的(de)(de)(de)內(nei)核(he)(he)版(ban)本，逐步地(di)、自動地(di)將(jiang)整(zheng)個(ge)平(ping)臺的(de)(de)(de)節(jie)(jie)點(dian)(dian)內(nei)核(he)(he)版(ban)本收斂起(qi)來。
另外，因為騰訊是一(yi)(yi)家一(yi)(yi)二十年的(de)(de)(de)老(lao)企(qi)業(ye)(ye)了，當將所有(you)資源都合并到一(yi)(yi)起(qi)后，就(jiu)會(hui)存在(zai)有(you)機(ji)(ji)型(xing)代次(ci)差(cha)異的(de)(de)(de)不同服務器(qi)硬(ying)件(jian)，而不同代次(ci)的(de)(de)(de)機(ji)(ji)型(xing)，算(suan)力是不一(yi)(yi)樣(yang)的(de)(de)(de)，如果(guo)同一(yi)(yi)個(ge)工作負載(zai)的(de)(de)(de)不同 Pod 位(wei)于(yu)不同代次(ci)的(de)(de)(de)機(ji)(ji)器(qi)上，這(zhe)就(jiu)可能(neng)(neng)導致(zhi)不同 Pod 的(de)(de)(de)負載(zai)極(ji)其(qi)不均(jun)(jun)衡(heng)。為此，TKE 研發(fa)了基于(yu)機(ji)(ji)型(xing)的(de)(de)(de)性(xing)能(neng)(neng)動態修改每一(yi)(yi)個(ge) Pod 對應的(de)(de)(de)路由權(quan)重的(de)(de)(de)能(neng)(neng)力。當一(yi)(yi)個(ge) Pod 底層(ceng)用的(de)(de)(de)是一(yi)(yi)些(xie)很(hen)老(lao)的(de)(de)(de)機(ji)(ji)型(xing)的(de)(de)(de)時(shi)候，會(hui)自動調低對應的(de)(de)(de)路由權(quan)重;當 Pod 底層(ceng)的(de)(de)(de)機(ji)(ji)型(xing)比(bi)較新的(de)(de)(de)時(shi)候，對應的(de)(de)(de)權(quan)重會(hui)更大。通過這(zhe)種方式，打平了不同 Pod 之間的(de)(de)(de)負載(zai)，用戶看到的(de)(de)(de)每一(yi)(yi)個(ge) Pod 的(de)(de)(de)負載(zai)都是均(jun)(jun)衡(heng)的(de)(de)(de)，最終達到對業(ye)(ye)務屏(ping)蔽機(ji)(ji)型(xing)差(cha)異的(de)(de)(de)目的(de)(de)(de)。
另外，不(bu)(bu)同(tong)(tong)可(ke)(ke)(ke)用(yong)區(qu)(qu)域(yu)(yu)(yu)的(de)(de)資(zi)源余(yu)量也不(bu)(bu)一樣。為了(le)解(jie)決資(zi)源問題(ti)，業務往(wang)往(wang)需要在(zai)不(bu)(bu)同(tong)(tong)可(ke)(ke)(ke)用(yong)區(qu)(qu)域(yu)(yu)(yu)之間來(lai)回騰挪(nuo)。為了(le)讓業務更加充分(fen)(fen)地利(li)用(yong)不(bu)(bu)同(tong)(tong)可(ke)(ke)(ke)用(yong)區(qu)(qu)域(yu)(yu)(yu)的(de)(de)資(zi)源，能(neng)夠靈活地在(zai)不(bu)(bu)同(tong)(tong)可(ke)(ke)(ke)用(yong)區(qu)(qu)之間調度，甚至做到(dao)業務不(bu)(bu)感(gan)(gan)知可(ke)(ke)(ke)用(yong)區(qu)(qu)域(yu)(yu)(yu)的(de)(de)屬性。TKE 應用(yong)管理平(ping)臺提供模糊可(ke)(ke)(ke)用(yong)區(qu)(qu)的(de)(de)能(neng)力，徹底屏蔽 K8s 節點、集群、可(ke)(ke)(ke)用(yong)區(qu)(qu)的(de)(de)概(gai)念，讓大(da)部(bu)分(fen)(fen)業務完全不(bu)(bu)感(gan)(gan)知這些資(zi)源的(de)(de)屬性，充分(fen)(fen)利(li)用(yong)不(bu)(bu)同(tong)(tong)可(ke)(ke)(ke)用(yong)區(qu)(qu)的(de)(de)資(zi)源，同(tong)(tong)時(shi)讓業務具備跨區(qu)(qu)域(yu)(yu)(yu)容災能(neng)力。
云原生路線圖
如(ru)果要總結騰訊(xun)云原生的(de)特色，那可能主要有三點。
第(di)(di)(di)一(yi)點(dian)(dian)是超(chao)大規模，這(zhe)種(zhong)體量規模至少在國(guo)內沒有(you)第(di)(di)(di)二家。第(di)(di)(di)二點(dian)(dian)是業務(wu)場景(jing)極其(qi)豐富，包括社交(jiao)、音(yin)視(shi)頻、游(you)戲、支付、騰(teng)訊地圖等等業務(wu)場景(jing)。第(di)(di)(di)三點(dian)(dian)，這(zhe)些騰(teng)訊自研業務(wu)對(dui)穩定性、容災要求非常高。
王濤總結(jie)說(shuo)，“我們做這(zhe)個事情(qing)(qing)最大(da)(da)的(de)壓力是要(yao)保證容器化之后業(ye)務的(de)穩定(ding)性，如(ru)果(guo)不(bu)小心把一個集群搞掛了，或者出現大(da)(da)面積的(de)節(jie)點宕機，影響業(ye)務運行(xing)，這(zhe)個后果(guo)就(jiu)非常(chang)嚴重。也(ye)就(jiu)是說(shuo)我們從一開始就(jiu)理(li)解到業(ye)務對(dui)穩定(ding)性要(yao)求極高，大(da)(da)家都(dou)是如(ru)履薄冰，做事情(qing)(qing)在細節(jie)上會考(kao)慮非常(chang)完(wan)善，因此 TKE 服(fu)務騰訊自研業(ye)務這(zhe)么(me)長時間，平臺沒有遇到過大(da)(da)的(de)故障。”
如今(jin) TKE 平臺在騰(teng)訊內部已經成(cheng)功承(cheng)載了(le)數以億計的容器，支撐眾多海量(liang)業務平穩運行(xing)，這(zhe)個持(chi)續(xu)三年的改造項(xiang)目，用鄒(zou)輝(hui)的話來講，它(ta)不是(shi)一錘(chui)子買賣，而是(shi)一個持(chi)續(xu)迭代、持(chi)續(xu)更新的過程。
騰訊根(gen)據自研業務(wu)以及目前一(yi)些(xie)外部企業使(shi)用 TKE 進行云原(yuan)生(sheng)改(gai)造(zao)的經驗，設計(ji)了(le)一(yi)個五階(jie)段的路線圖，希望能夠給其他(ta)企業帶(dai)來參考。
