企業級雲原生:TKEStack 騰訊雲原生開源實踐之路

導語丨TKEStack 是騰訊開源的一款集強壯性和易用性於一身的企業級容器編排引擎，是開放原子開源基金會的孵化項目之一。本文是對TKEStack 開源項目負責人汝英哲、TKEStack 高級產品經理何鵬飛在雲+社區沙龍online的分享整理，介紹 TKEStack 的開源方法論，希望與大家一同交流。

點擊視頻查看完整直播回放

一、TKEStack 簡介

TKEStack 是騰訊雲開源的容器平臺，很多小夥伴們問：有了 Kuberentes 為何還要用 TKEStack？其實 Kuberentes 作為能力平臺還有很多欠缺。比如它沒有UI、鏡像倉庫、權限管理、日誌、監控等基本運維能力，單把 Kuberentes 作為一個業務平臺還是很單薄的，而容器平臺補齊了以上這些功能點，把 K8S 封裝成了完整的業務平臺。

TKEStack 的開源歷程

騰訊很早就開始做容器相關的計算平臺了。2009 年吳軍博士從谷歌來到騰訊，便借鑑了谷歌做出了騰訊自研的業務平臺 T-Borg。到了 2011~2013 年左右開始用社區成熟的公認的技術做業務平臺。當時有一次重要的技術方向轉變，轉向使用業界主流技術方案後，Torca 轉向專門做大數據業務平臺，於是有了HOT（hadoop on torca）。到了 2014 年，Docker 技術也體現了威力，我們非常看好 Docker、Kubernetes 技術，於是迅速進行了切換，並且著手開始做通用的業務平臺。

2014 年也有了全新的產品 GaiaStack 用來支持騰訊內部業務，2019 年騰訊做了業務整合，有多條業務線的合併，Kuberentes 和公有雲業務團隊合作推出了 TKEStack 的容器平臺，整合了 Kuberentes 的技術能力。Gaiastack和TKE的技術結合形成了 TKEStack 這個產品，並在 2019 年正式開源。

今年，又有一個非常重要的時間節點，就是上個月 TKEStack 正式加入了開放原子開源基金會。

二、產品定位與方向

1. 容器是雲原生的事實底座

在介紹整個產品的定位和方向之前，首先要提一下目前最火熱的技術方向 —— 雲原生。

雲原生是利用公有雲、私有雲和混合雲構建和運行可拓展彈性的應用。容器基本上是整個雲原生技術棧的底座角色，CNCF 官方來看容器族的產品中已經有大量產品和廠商參與其中，基本上是百花齊放的態勢。

眾多產品中，真正耳熟能詳的產品主要有兩個，分別是 openshift 和 rancher，它們是容器開源界的標杆。

首先是紅帽的 openshift，大家從 K8S 的代碼貢獻可以得知，紅帽 K8S 代碼貢獻率僅次於 google 排第二，技術能力非常強，產品也非常的完善，並且很早便開始做開源產品了。另一個是 rancher，今年被 suse 收購，產品體驗非常好。

但在國內企業的使用場景中，這兩個產品也有一些不太完善之處。

首先是國內外用戶習慣的差異，國外的產品，更多照顧了國外用戶的使用習慣。國外用戶喜歡用小而專的產品，喜歡命令行工具。但國內大部分用戶希望用一站式的平臺，要界面化和一站式服務。

另一個問題點在於，國內下載一些國外產品的鏡像，網絡是個大問題，經常會網絡不通或者非常慢，導致使用體驗極差。

因此 TKEStack 做一個容器產品需要考慮如何定位這個產品，TKEStack 並不是要在基本體驗和全局完善程度上和 openshift、rancher 去對標，他們已經做的非常成熟了，我們剛剛開源，很難在短時間一下子就可以達到他們的成熟度。

2. TKEStack 的開源思路

騰訊雲的思路是尋找雲原生的藍海，我們認為在未來，多雲以及硬體異構和硬體平臺異構是一個方向。

從 2009 年開始騰訊在容器技術方面有很多積累，內部業務在雲原生領域也有很多的積累。基於騰訊自己的技術優勢和積累以及我們對國內用戶訴求更為了解，我們計劃基於這兩個點做一些雲原生的開源產品，為雲原生生態貢獻騰訊的力量。

（1）硬體異構

首先是硬體異構，絕大部分的使用場景是基於 X86 的硬體，但國內有一個很重要的訴求是支持 ARM。騰訊會做到X86 和 ARM 可以在同一個集群內部署。GPU 方面除了有自己傳統的比較有優勢的 GPU 虛擬化能力以外，也把英特爾 GPU 能力和寒武紀和華為的 GPU 相關產品 在 TKEStack 裡面做適配，讓上層用戶可以無感的使用。

（2）基礎架構異構

基礎架構異構就是混合雲，TKEStack 架構設計上是拿一個集群管其他的集群，天然可以做到混合雲，把別的集群，自建集群註冊到 TKEStack 裡面來，利用 TKEStack 提供的鏡像倉庫、認證、日誌、權限、監控，在一個 TKEStack 界面來可以管理多個 K8S 集群。

騰訊積累了一批雲原生應用相關的技術方案，兩個比較為人熟知的是有狀態應用的 TAPP 和英偉達 GPU 虛擬化，還有一些大數據套件也在做集成。騰訊希望把內部的優勢開源組件一步一步往 TKEStack 裡面集成，在用戶可以 在TKEStack 上使用。

（3）鬆耦合

除此以外還有一個比較重要的點就是鬆耦合，TKEStack 一方面支持自研業務，另一方面也支持商業化產品，最終呈現給用戶態的不止一個產品。用戶直接用的開源產品，內部用也有變化。

面對這樣的訴求，就要求 TKEStack 要做到可插拔、積木式組裝。A 產品要用日誌，B 產品不用日誌，自己可以選擇可以隨意的組合，TKEStack 是具備這樣的鬆耦合能力。

三、開源方法論

TKEStack 從去年 11 月份開源以來，在差不多一年的時間裡已經積累了不少經驗，也採用了不少方法，感謝資深開源專家馬全一老師的指導，現在除了可以對外貢獻代碼和技術以外，也把經驗積累以方法論的形式體現出來，下文為大家分享一下開源治理模式的經驗和總結。

1. 為什麼要開源

為什麼要開源？這個問題在很多搜尋引擎上有不少答案，但更多的是偏向於開源對於個人的發展以及開源對整個社會的價值的角度來看的。騰訊更多的是從作為一個企業或者一個部門，對外開源一個項目能夠給公司和企業帶來哪些優勢來考慮的。

只有能夠商業落地的開源項目才能獲得發展繁榮的機會。近年來 IT 行業的發展中，有幾個大家耳熟能詳的大項目，Apache、Linux、CentOS 等等，這些都有非常深厚的開源背景和商業落地歷史。

開源首先就是能夠為商業版本市場推廣上帶來巨大的馬太效應，強者越強、弱者越弱。Apache 首先有了開源項目，然後在開源項目知名度打開後越來越多的用戶或者是開發者加入項目中來，開源的用戶自然的轉化為商業版本的用戶或者是商業產品的應用。用戶想要完善商業版本，很自然的就會到開源版本社區上為社區貢獻自己的代碼或者是他的體驗優化，形成了良性循環。

開源是對商業版本的重要支撐，開源的社區能夠為商業版本產品貢獻資源和力量，也是開源商業產品去豐富自己的功能特性和環境適配、是構建完整生態的重要支撐。

有些客戶對業務會被某一家供應商所綁定的問題比較敏感，給用戶提供開源的商業版本就會減少他們的顧慮，他們也會更樂意支持開源項目。

整個開源商業以及生態互相支撐、相互的建立標準、形成生態，最後落地為一個商業市場的行為，變成良性循環，把開源項目、商業項目越做越大、越做越好。

2. 開源項目為什麼需要方法論

以剛剛提到的幾個大項目為例，最開始的項目其實完全是由一些傑出的開源工作者按照個人的喜好和熱情推動了整個開源的起步。

但是如果看今天各種的項目，能夠形成巨大社區或者產業的巨大項目，僅靠個人的熱情是很難推動和完善的。這樣的大產業項目迫切需要有一套方法論來支撐和引領開源項目制定戰略、規劃特性、構建標準、建設生態，一步一步環環相扣。

如果是 to C 的商業模型的開源項目，生態是重中之重的要建設的點。如果是 to B 的項目，會尤其看重合作，合作夥伴的選擇和治理方式對開源有著非常重要的意義和價值。

3. 開源項目架構

（1）金字塔模型

開源項目的整個架構首先是開源戰略的金字塔模型，企業開源整個金字塔塔尖的位置首先要制定好戰略，只有制定好了戰略，指明了未來產品或者是項目的發展方向之後，才有了後續的標準、產品、生態。

戰略是指明了大方向的前提，是整個開源項目的靈魂。開源之前大家一定要想好做產品或者是做項目想要讓它達到什麼樣的效果、未來的發展方向是什麼、或者更加理想中的未來世界的開源項目能夠站在什麼樣的位置上，為大家貢獻怎樣的力量，戰略是靈魂也是核心。

項目要遵循標準或者是行業的事實標準，可以更加關注開源項目能否形成行業標準或者是事實標準。當然不必非得是具體條文、接口規範，也可以是隱性的標準，比如操作習慣、UI界面設計等等，指引和影響用戶人群的觀念和習慣，帶來潛移默化的形成一套隱性標準。

圍繞標準、圍繞戰略設計開源項目，把開源項目真正當做一個產品來設計，意識到開源項目是有它的開發者、有對應的用戶、有真正的使用者，不是我們想怎麼做就怎麼做的，而是把開源項目當成一個真正產品來做、做到越來越完善、越來越完備的狀態。

最後以產品、以項目為核心建設生態，同時把生態轉化成商業的載體，這是企業開源戰略的金字塔。

（2）沙漏模型

接下來開源項目治理的模型，或者真正要把整套的開源項目運轉起來。整個沙漏最重要的部分的是瓶頸部分，開源項目就是產品，產品就是我們的重中之重，開源項目最終呈現給客戶就是以開源項目為核心的整個產品。

而產品的基石就是核心開發者，核心開發者可以掌握整個項目發展方向，維護社區的穩定。

這之下是使用開源項目的商業夥伴，他們非常有動力完善 TKEStack 的功能、優化和提高 TKEStack 的產品質量和體驗。

在此基礎上也有更多來自於社區或者來自於其他團隊的上遊開發者，他們會為 TKEStack 貢獻大家的各種環境的適配、各種特異化的功能豐富 TKEStack 的產品線。

（3）生態夥伴模型

對於 TKEStack 來說，企業開源項目的重心重點是生態夥伴，合作夥伴怎麼來選擇怎麼來合作，就形成了生態夥伴模型。

合作夥伴分為幾大類，首先是核心開發者以及 TOC 技術委員會，這是整個開源項目的核心，只有核心團隊穩定後才可以保持 TKEStack 整個開源項目的穩定。

首先 TOC 技術委員會可以包含創始人、團隊的導師、架構師、產品經理、運營經理等等，是以一個委員會的形式確定整個開源項目的發展方向。核心開發工作者社區可以來自於公司的內部，或者是來自於重度使用的團隊貢獻整個開源項目核心的代碼和架構部分。

除了核心工作者提供以外也有忠實追隨者，比如投後的公司、對於項目有非常忠實的粉絲，他們會為整個項目貢獻他們的活力、貢獻他們在商業場景上的適配或者是客戶真實需求都可以在開源項目上努力實現。

一個開源的項目對外是要有開放包容的態度來歡迎各類開發者甚至是競爭對手一起合作，競爭對手某一個角度上、某些場景上也可以找到一起合作的點。大家的出發點都是站在開源的角度，都是為了整個生態和社區服務的，從這個角度上來看跟客戶或者是跟個人開發或者是競爭對手合作起來會比較容易談成。

制約整個項目成功的要素首先還是要選擇正確的核心的合作夥伴，爭取中間位置的合作夥伴，總的來說是要爭取更多的開發者的力量，朝著一個目標貢獻開源的社區力量。

4. 其他制約項目發展和成功的要素

針對於這套方法論還要有一套能夠適配於這個方法論的治理模型，能夠把方法論和開源理想落地實現，要有豐富的市場手段宣傳開源項目、宣傳商業產品。同時，這樣也是整個開源社區或者是產品和項目是非常好的強心劑，能夠助推項目更好更快的發展。

四、開源治理模式

1. 開源項目全生命周期治理

TKEStack 開源項目是有生命周期治理的，從最開始戰略的規劃、到產品需求、開發迭代、發布周期、運維管理、運營管理，各種的階段都是有著自己的流程和方法的。

對於戰略計劃和需求而言，戰略計劃會有定期的TOC的技術委員會會議，周期是半年或者是一年的年度計劃或者是半年計劃，以此來制定整個 TKEStack 的年度裡程碑。

制定完之后里程碑和路線圖會在代碼託管網站上公布出來。後面會就路線圖進行細化，真正落實到每天的工作中，以周會的形式來跟蹤裡程碑和路線圖。

具體實施階段，一是內部的用戶反饋、二是外部的用戶反饋。內部客戶會有一套 TAPD 需求管理系統來跟蹤整個狀態，外部用戶則使用Github Issue跟蹤。

2. 需求流程

由於對外開源，所以有大量的外部用戶的需求和問題反饋。如果沿用之前流程，按照兩條線分別進行需求開發跟蹤會造成大量衝突和混亂的問題，產品經理會非常累的奔波於兩條線上，統籌內外部的需求。

對於這個問題，我們進行了改進，做到了自動化。比如外部的需求和問題單，有自動化任務每天同步到內部系統中來，公司內部核心開發人員就可以看到外部客戶的需求，並且第一時間進行評審，給出他的開發意見。

對於比較大的需求，給出的開發建議或者是概要設計我們也會提交 Proposal 供給整個社區的人看到。

3. 開發流程

開發流程包括開發中、測試和最後的提交，都可以整體在系統中追蹤得到，並且也能夠及時的同步到 Github 開源網站上，公司內外部的用戶和團隊能夠第一時間掌握整個需求的狀態。

開發流程沿用的是Github 標準的開發流程，創建分支、創建PR申請、討論以及最後的部署、測試等等，具體的詳情可以參見 Github 的官網。

4. 測試流程

開發流程另一方面就是測試流程，現在 TKEStack 能夠做到三級測試，每個測試所在的階段和目標也不盡相同。

UT 是在每次的代碼編譯時候保證整個代碼的可編譯性、以及語法沒有重大錯誤。SmokeTest 每次 PR 提交的時候運行，大概有十幾個測試用例來保證提交代碼不會影響到 TKEStack 的核心功能，最後每次發版的時候也有release 測試，來保證最後發布的版本可靠性。這是三級測試的流程。

5. 發布與維護

發布也有自己的一套版本發布和分支管理的流程。下圖中標紅色線的是主分支，就是長期跟蹤的分支，所有的fix，feat，docs等等代碼全部都是要提供到主分支上的。

主分支上會按照計劃去發布版本，比如發布的版本是 v1.4.0，就是按照計劃在主分支上找到合適發布的版本，從上面拉取 release-1.4 的分支，發布的時候將 v1.4.0 的標籤打到分支上，這個 v1.4.0 的分支就是我們要長期維護的分支。後續如果有 bug 修改也都會在這個分支上同步發布，也會定期在分支上發布 v1.4.1 的小版本。這些整體的版本發布維護計劃都是可以看到的。

6. 社區治理

整個治理模型最後部分是社區的治理，對應於之前提到的方法論，吸引各種合作夥伴和團隊參與到整個開源社區治理中來。

團隊內部的核心開發者、公司內部的貢獻者是負責 TKEStack 核心功能，要保證產品發展方向和核心能力的，分配的是基礎架構方面的工作。

外部的合作夥伴更多的優勢是在於他們能夠結合環境的適配面對真正用戶做特質化的需求，這是對產品功能方面非常重要的，也有更多的參與商業化的構建，以及特定的功能，比如日誌、監控等等其他的針對於用戶環境的優化需求。

社區內的大量開發者也可以有更多的優化體驗，一些業內更好更新的實踐或者是方法都可以來參與到社區中來。

對於各個開發團隊或者是對於社區個人開發者，騰訊也做了很多努力，比如組織線上線下的活動來宣傳介紹相關知識，例如TKEStack 最近有在做開源懸賞任務，會定期的放出一些開發任務交給大家來參與進來。騰訊也會以各種獎勵來回饋社區、提高大家對參與社區活動的積極性。

五、案例介紹

1. 內部上雲

騰訊現在整體在做全量業務上雲，這是一個過程，有些業務依賴的周邊系統的業務還沒上雲，所以難以短時間直接切換為共有雲部署。

另一方面，業務上雲需要有一個中間過程，而且雲機房的機器和 IDC 機房的機器不同，當把業務全部切到雲上，IDC機器就空閒了。

為了解決這兩個問題，TKEStack 在內部部署了一套用來支持業務上雲。TKEStack 界面和公有雲一脈相承，兩個產品的使用體驗上沒有大的區別。所以暫時還無法全量上雲，但又必須要做雲化改造的商品，現在可以藉助TKEStack完成雲化，條件成熟進一步上到騰訊公有雲上，TKEStack 已經支持了大幾百萬核的內部業務運行。

2. TKE 企業版

TKEStack 企業版除了在開源也在支持內部業務，同時也支持商業化的產品。相比內部資源上雲，商業化的企業版在很多方面會做更多強化。

TKEStack 企業版界面跟開源 TKEStack 有些不同，開源的TKEStack在基於商業化訴求界面上封裝得更多、展現的內容更多。

TKEStack企業版的核心能力，比如集群的調度、創建、業務管理比較核心的底層能力是TKEStack貢獻，但是在微服務方面以及運維和運營相關的比較強用戶體驗的功能更多的是企業版自己構建的。這就是拿一部分開源底層能力和商業化特殊要求的能力進行組合，就會變成TKEStack企業版，相互不會影響彼此。

六、總結和展望

開源類似於創業，要做到天時地利人和。

天時，是對的時間做對的事，比如目前大家都在做雲原生，這個時候做容器平臺就可以吸引到用戶，如果做一個openstack平臺， 相對吸引力就不是那麼強，所以正確的時間做正確的事情，跟隨主流技術趨勢是天時。

地利，有了好的方向後也得有能力做。騰訊在這方面有著十多年的積累，技術能力比較強，既有內部業務的使用經驗，有騰訊公有雲的運營經驗，也有大規模集訓支撐能力，這幾者結合可以說做開源的容器平臺有了技術的基礎。

人和，目前在國內很難有這樣的機會有一撥人完全做開源，長時間的關注在開源領域沒有任何業務 KPI，這是理想化的過程。實際上的過程是既要支持核心業務，又要做好開源產品。

在兩者間綜合協調，要有合適的戰略推動這個產品持續的迭代，有了產品後也需要更多人參與生態中認同這個生態，使用、維護，並且對生態做出貢獻。有更多人參與這個產品才更有生命力，才算得上是合格的開源產品。

這是天時地利人和，商業化的賣一個產品也是一樣的道理，好的商機、有做產品的能力，有對的人做出受歡迎的產品。

未來的雲計算基礎設施一定是處於多維異構的狀態。多維是三維，硬體是異構的、基礎設施是異構的（公有雲和私有雲）、業務也是異構的，不光跑一些非常簡單的無狀態服務也要跑有狀態任務，包括在線業務、離線業務等等。

我們希望在多維異構的層面為用戶提供一站式的通用的基礎架構平臺，這是 TKEStack 的願景。

TKEStack 在今年 10 月發布了 1.4 版本，主要的核心點包括應用市場、導入集群支持安裝插件，也有集群小版本升級功能逐漸上到 TKEStack中，同時修復了大量體驗相關用戶反饋問題。

今年 12 月，TKEStack 還會在幾個重要的點進行升級，比如大數據組件的集成，要把騰訊雲優勢產品持續和 TKEStack 同步。我們會在年內把優秀大數據套件集成進來，TKEStack 一鍵就可以部署常用的大數據套件。對一個集群高可用也是業界的難點，私有雲環境有太多不可知的因素，在這個場景裡是很麻煩的。

明年，TKEStack 會繼續往上層發展，比如做應用的複製，至少要有完整使用騰訊雲公有雲所有產品的能力。

目前，對於 TKEStack 整個平臺升級呼聲比較大的是 IPV6，但這一點要等官方 IPV6 的正式支持。明年騰訊的公有雲和混合雲也會有更豐富的能力，比如全部的 DNS 服務可以多集群接入，集群遷移也可以提供更多的工具的方法，更簡單無門檻的做整個K8S集群的遷移，或者是做容器化的遷移，這些能力的提升可以真正解決許多用戶的共同問題。

Q&A

Q：TKE 如何實現服務發現呢?

A：我們暫時沒有額外做更多的服務發現的能力，就是K8S原生的service服務發現機制，但是下一個版本很快會集成自己的Service mesh產品，走雲原生的路線。

Q：外部需求都是主要哪裡來的呢，都是客戶嗎?

A：我們在 Github 開源，社區中有人提出需求來我們也有產品的同事來看，會拿出來看是否適合做，如果適合也會做進來，當然也分輕重緩急。

Q：大數據組件集成了哪些呢？

A：當前版本裡沒有集成，今年年內會爭取放上來，會包含常用的大數據、AI組件，容器化部署會在這個大包裡，因為現在還有智慧財產權相關問題要處理，我們希望年內把它集成到 TKEStack 可以一鍵部署，真正讓大家大數據和 AI 業務可以 TKEStack 上跑得更好。

Q：TKEStack的運營體系是如何建設的?

A：運營體系剛剛也介紹了，再簡單說說，主要是有內部的核心開發者、商業化推動開源產品持續有人做這件事，光幾個開發者肯定不夠，也會去吸引更多人進入，一方面吸引內部技術團隊，比如騰訊雲其他的部門，他們在容器化過程中也有很多產品能力我們也會吸引進來，也有多家的商業合作夥伴，商業化方面有些合作夥伴做了好的能力可以反哺給 TKEStack，或者是給 TKEStack 提了一些需求，他就自己實現了，也可以把這部分提交過來，商業合作夥伴也在持續為 TKEStack 做貢獻。

外部的用戶也是現在重點在發力想吸引更多用戶進入跟我們一起建設，對於一個容器平臺這麼大的項目，我們希望有更多的人參與進來能夠把整個產品做得更完善，接下來正在醞釀一些活動，比如開源獎賞相關活動，比如加入開放原子基金會也希望其他的用戶可以參與到 TKEStack 中來。

Q：請教下老師TKEStack是如何來設計自身的監控的？

A：目前雲監控普羅米修斯就是事實上的標準，所有的雲產品和容器產品都是用普羅米修斯做監控，我們會給每個業務集群裝一個普羅米修斯插件。目前業界受歡迎的 thanos 方案內部業務也應用起來了，下一步也會整合到 TKEStack 中來，未來 TKEStack 默認帶普羅米修斯，如果是高可用我們會提供可選的 thanos 方案。

Q：TKE有幾個版本呢？

A：主要有公有雲的容器服務TKE，以及騰訊專有雲裡面的TKE，另外，就是獨立部署開源版本TKEStack；以及基於開源版衍生的商業版本TKE 企業版、TCNP。專有雲TKE沿用公有雲TKE的技術實現和產品形態，依賴公有雲或專有雲中的IAAS資源，例如雲主機、 VPC。獨立部署的版本，基於裸機和開源方案部署，不依賴其他資源。

Q：TKEStack必須要使用 Kuberentes 嗎，和 Kuberentes 有什麼關係？

A：是的，因為是基於 Kuberentes 做上層封裝的，Kuberentes 如果直接用就是命令行，可以做各種調度，但是用戶怎麼登錄、控制臺如何管理應用、監控哪裡看等等，TKEStack 是基於 Kuberentes 做上層封裝，把 Kuberentes 真正變成可用的業務平臺，這是 Kuberentes 和 TKEStack 之間的關係。

Q：TKE 的 configMap什麼時候能實現自動發現更改，重新部署服務，而不需要人為？

A：TKEStack支持原生的K8S configmap功能，現在只是有一個界面化暫時沒有做，很快當前正在開發的版本已經做UI化，下一個版本就可以用到跟公有雲一樣UI上的設置的產品能力了。

Q：SmokeTest 和 ReleaseTest 的 test case 有什麼區別呢？

A：每次PR提交的級，會主要偏重於測試這次代碼提交不會影響整個TKEStack 的基本核心功能，測試用例時間也有要求的，儘量在一個小時或者半個小時內完成的，它是簡單的測試集、核心測試集，而每次版本發布前也是自動化的release測試，目的是為了評估版本，對版本的質量的保障，所以測試集是全方位的保證測試的質量。

Q：和 Racher 有什麼區別？

A：Racher 是技術體驗做得非常好的產品，非常成熟的產品。TKEStack 的重點方向是基礎體驗達到可用、不會太追求特別多細節，因為很難短時間同等級別好用，更多的是異構集群、混合雲、插件提供方面重點發力，但是技術體驗也要持續保障，使用上的問題歡迎大家提出來。

Q：TKE跨集群 vpc 訪問採用服務發現有實現麼？

A：現在已經支持多集群相互間的服務發現，TKEStack 本身沒有做我們也在規劃混合雲相關產品能力，明年上旬混合雲是很大的項目，並不是只有服務發現問題要解決，也有網絡問題、集群版本不同、插件不同問題等等都要解決，大概明年上半年完成。