專訪K8s核心App小組主席，揭露K8s未來2年重心要支援GAI運算

2014年Docker問世掀起了雲原生浪潮，隔年，Google就發表了Kubernetes（簡稱K8s）。Google主任工程師Janet Kuo正是在2015那一年加入了K8s團隊，是這個平臺第一代推手之ㄧ，一路參與至今。

2015年，Janet剛進入Google要選擇部門時，遇到Kubernetes（簡稱K8s）團隊開始招募人手。K8s創辦人告訴Janet，如果加入這個部門，不只能改變全世界執行雲端運算的方式，讓AP更有效率，自己開發的程式碼，還可以在全世界的機器上執行。

聽到這個新專案將有極大的影響力，Janet決定加入。當時K8s團隊約30人規模，分散在矽谷、西雅圖和華沙三個據點。在數萬名員工的Google中，這是一個很小的團隊，沒想到卻打造出了一個影響全世界雲端產業的關鍵平臺。

K8s部門下設立了不同的SIG（興趣小組），各自負責開發不同功能的元件，Janet是Application SIG小組的主席和技術領導人。這個小組主要負責維護Workload API，還有開發者部署常用的Deployment元件和Jobs元件等。Janet也曾擔任過KubeCon總召，要負責規畫該年活動所有的演講。

K8s近10年最大貢獻是成為雲原生技術的共通標準

Janet觀察，Kubernetes近十年來最重要的貢獻是，讓任何部署都可以很容易轉移。因為K8s提供了一個一致的標準，不用考慮在哪一朵雲或是在哪一種環境中執行，讓AP從一個環境很容易就可以轉移到任何一個環境。

K8s現在可以支援從雲到端各種不同的環境，來提供統一的管理。有一個雲端供應商的SIG，就是想辦法確保K8s對各種環境都是中立，不偏袒任何一家。一方面會有相容測試來確保每一家業者的K8s服務或K8s環境，都能提供主要核心功能。另一方面，K8s專案也會將個別雲端業者維護的程式，移出K8s核心，確保核心沒有一個限定雲端使用的程式，來確保K8s的通用性，不會受限於雲。這是為了讓K8s可以適應各種更複雜的環境。「K8s所有的東西都是開源，想要自己改就能動手。正因為開源，就不會偏袒任何一方，也才確保使用者優先的立場。」Janet指出。

隨著越來越多人用，K8s成了業界逼準，也讓企業更容易招募人才，甚至連雲原生Cloud Native這個詞都是在Kubernetes誕生後才出現。現在基於Kubernetes架構上可能多達數百款雲原生工具或技術，涵蓋了打造一隻AP所需要的每一層工具，例如不同服務之間溝通的Service Mesh或是用來打造Serverless服務的工具都有。開發工程師不用熟悉大量細節，就能打造出一隻Serverless應用。「從底層控制，到最上層，都可以用同一個框架。」她補充。

有了這樣一套雲原生技術的共通標準，所有AP只要用雲原生方式，就能相互溝通，也能有很好的整合。如此一來，Janet表示，只要使用Kubernetes，所有使用者和開發者，都可以更有效率地部署程式碼，不只可以加速企業開發速度，各種新應用和新技術的發展腳步也可以更快。 

「大家都熟悉同一套技術，用來搭建API的工具更可以重複使用，」這正是K8s帶來的另一個重要價值，她解釋：「容易擴充，任何人都可以在這個平臺上打造自己要的API，訂定自己要的維運邏輯。」這個特性也促成K8s周邊的生態圈非常發達，任何人很容易就能利用其他人開發的建置工具。 

為何K8s可以成為打造任何平臺的萬用平臺

首次來臺在Kubernetes summit開場主題演講時，Janet特別推薦K8s的API工具，這是用來打造客製化API，操作叢集的機制，稱為Kubernetes API，很容易就可以快速打造出一支客製化API，與K8s後端叢集互動。「這個工具最重要的意義是，提供了一種標準化的API產生方式，也是一種快速擴充的工具，這是發展生態圈的重要基礎。」她強調。

「Kubernetes API改變了人們打造平臺的方式。」Janet指出。她指的平臺，像是維運人員或是SRE所打造的平臺，如企業維運平臺，或是內部開發者平臺，可以讓開發者更快速部署自家AP，不用從頭打造AP運作底層的每一個細節。這類平臺會提供像是應用程式驗證、AP範本、部署樣板等，讓開發團隊參考，也可以預先考慮基礎架構的資安機制來設計等。「在K8s問世前，要打造這類的基礎架構維運平臺非常複雜也相當耗時。」她補充。

Janet指出：「Kubernetes能夠成為一個可以打造任何平臺的平臺，關鍵就是透過Kubernetes API來管理自己的AP，也能結合企業政策，更能管理AP背後的基礎架構，建立自動化管理又容易擴充的維運平臺。」

原本K8s的核心API約可以滿足8成常見維運的需求，若企業想要增加需要的客製化功能，一是向社群提出新功能提案，慢慢等待社群的釋出。另一個作法是用Aggregated API Server來自己開發一隻專屬API，「這個做法很有彈性，但相對複雜許多。」Janet補充。

K8s客製化API最常用也是最推薦的作法

她推薦的是第三種方法，這也是最多人採用的做法，就是使用CustomResourceDefinition API（簡稱CRD API）來定義一隻Kubernetes API，成為Kubernetes API Server可以管理的延伸API之一。

CRD API也是K8s內建API，只要定義好API的資料架構，很快就能建立一隻新的API，更關鍵的是，「這隻客製化API，用起來就像是K8s內建的API，」她補充，如可以支援多版本功能，讓開發者自行選擇要用的版本。透過CRD API產生的API還能與Kubectl整合，直接在命令列中呼叫。更關鍵的是，透過CRD定義的API，容易與K8s生態圈其他的產品整合。許多K8s生態圈的產品，例如無伺服器框架Knative，都是透過CRD來打造產品的API。

這個K8s API很適合用於發展開發者平臺，企業需要快速產生各種API來操作他們的AP，只要定義了資源，撰寫出控制器，可以簡化一隻API的開發，甚至可以切換到不同資源的環境中使用。從維運角度來看，透過K8s API可以提供一個標準的API產生框架，開發者平臺若能讓開發人員透過同一套標準化方式和管道，來產生新的API，就更容易打造一個自助式的內部API管理平臺，可以讓維運人員更有效率，也能夠讓AP開發人力更聚焦在商業邏輯。

K8s發展戰略轉向：從底層調度轉向應用層，GAI優化是新方向

Kubernetes的版本發展速度很快，今年底很快就會釋出1.29版。身為K8s核心的Application元件小組技術領導者，Janet透露：「未來最大的發展方向是，如何讓K8s更有效率也更有擴充性。對於新崛起的生成式AI的工作負載，也要思考如何提供更好支援。」

追求更好的效率和擴充性，是K8s一直以來的發展目標，但是，提供生成式AI（GAI）更好的支援，則是今年開始的新方向。例如在Janet所領導的Application小組正在規畫，如何調整K8s的Jobs API，讓ML工作量在K8s執行得更順利。

「K8s的發展已經從運算資源的調度，開始延伸思考到應用目標，」Janet強調：「這是K8s發展戰略上很大的改變，從底層轉到應用層。」K8s開始針對特定情境的應用，尤其是未來非常重要的應用，例如GAI運算的支援，將是K8s未來2年的重要方向。

K8s既有的設計，還沒有考慮到GAI運算任務特性來優化。例如AI/ML運算任務之間需要傳遞參數資料，K8s有個可用於一次性處理或批次平行處理任務的Jobs功能，採取了無態式處理的設計，「不同Jobs之間無法傳遞狀態，就不適合用來處理AI/ML運算。」Janet坦言，開發者通常得自己得花額外力氣，自己處理這個問題。

雖然開發者可以在K8s平臺之外自行傳遞Jobs的狀態，「若能在K8s底層，提供這類Jobs間的狀態傳遞能力，K8s就能更容易支援AI/ML工作流程，或是支援不斷迭代的AI訓練方式。」

Janet提出另一個支援AI/ML運算的K8s優化方向是，考慮增加Jobs底層的Log機制，讓K8s維運人員更容易搜集這些Jobs的執行數據來優化效能，可以用來支援特別講究效能的AI任務。「K8s希望讓AI工作量更有效率地在K8s上執行，也想讓Jobs API支援各種AI工作量的需求。」

不過，Janet坦言，K8s核心不會引進生成式AI技術，而是，她認為，GAI可以協助來產生更有效率的k8s配置，也很適合用於學習K8s。例如可以自動生成YAML配置檔的維運AI助手，成為K8s學習助理，或是用AI來推薦K8s工具。「不少人抱怨K8s太難學了，我希望GAI可以降低K8s的上手門檻。」未來甚至使用者只要說，幫我建置什麼樣的Ap，在哪裡執行，GAI就可以自動產生相關的配置，甚至自動建立相關的叢集。 

2015年，Janet這位第一代K8s團隊推手剛加入時，最苦惱的是當年沒有人想用K8s，她的團隊花了一年到處說服和尋找使用案例。直到2016年，Pokémon GO遊戲爆紅，上市兩個月下載量超過5億次。

雖然直到2023年，不論Google或是Niantic，都沒有透露Pokémon Go到底用了多少伺服器來撐住爆量玩家的連線和運算需求，只透露比原本預期的最大流量，還暴增了50倍。

但在Pokémon Go正式上線的同一天（2016年7月6日），Kubernetes發布了1.3版，單一容器叢集可以支援到2千個節點，最多可支援6萬個Pod叢集，相當於最大可以提供到1.2億個容器。

Janet沒有透露更多細節只說，這個遊戲完全在K8s上執行，他們是第一個案例，也是有史以來的最大規模的K8s叢集。好不容易才說服他們願意公開，讓Google對外宣傳。大家才知道，原來Kubernetes可以處理到這麼龐大的流量，而且是來自全球使用者。

當時才數十人規模的K8s團隊全都派去支援Niantic，連Janet也不例外。「對外公開那一刻，我覺得參與K8s的打造，真的是太好了，那是我最有成就感的一刻。」文王宏仁