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