100年后 K8s 還會存在嗎？創始人 Brendan Burns：它將像 Linux 一樣消失在 AI 之下

軟件的宿命，最終都是走向死亡。（The inevitable trajectory of software is death.）

編譯 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

K8s 最早的 MVP，大概花了不到一周就寫出來了。

幾個人，幾臺機器，一個很粗糙的 demo：能把容器分發出去，能做最基礎的負載均衡，進程掛了能自動拉起，升級時能從 v1 切到 v2。放到今天看，這樣的開場甚至有點寒酸。很難把它和后來那個改寫了云原生格局、幾乎重塑了整個云計算語言體系的Kubernetes聯系在一起。

但這段歷史最值得回看的，恰恰不是 Kubernetes 后來如何成為事實標準，而是它在最開始為什么必須被做出來，而且必須被開源。

今天看到Brendan Burns（Kubernetes 聯合創始人，后來參與創辦了 Heptio，如今在微軟 Azure 擔任 Technical Fellow / CVP）的最新訪談，最有意思的地方，不是他又復述了一遍 Kubernetes 的成功史，而是他把很多人默認已經寫進歷史的事情，重新拉回到了那個還沒有結果的時刻：

• Kubernetes 最初只是一個幾天拼出來的 demo，但 Brendan Burns 當時就已經意識到：這種東西不可能永遠只屬于一家云廠商
  

• Google 開源 Kubernetes，不是因為理想主義，而是因為最現實的判斷：你不做，別人也會做，而且你會失去定義它的機會
  

• Kubernetes 后來統一了整個云原生生態，但在 Brendan 看來，它最值得回看的，反而不是崛起，而是它總有一天也會退場
  

• 真正成熟的基礎設施，往往不是突然死掉，而是像 Linux 一樣，活著，卻越來越少被人單獨討論
  

• AI 時代最可能發生的，不是 Kubernetes 被正面擊敗，而是它被埋進更深的一層，變成默認存在、但不再被看見的系統地基

以下為這場對話的全文翻譯。

Google 為什么非做 Kubernetes 不可?

Q：如果當年你要向 Google 管理層解釋，為什么要為整個行業去做 Kubernetes，你會怎么說？

Brendan Burns：其實早期最難的部分，不是把項目做出來，而是把這件事講明白。

在我們自己腦子里，這件事很清楚，但怎么把它說到足夠有說服力，讓別人也認同，并不容易。我們當時大概是從幾個角度去講。

一個很重要的背景，是MapReduce 的教訓。那時候 Hadoop 和所謂的大數據革命都很熱。Google 寫了最早的 MapReduce 白皮書，但后來真正被行業廣泛采用的，是 Hadoop 這個開源實現。Google 提出了最初的想法，可生態并沒有圍著 Google 轉。別人讀了你的論文，做了一個相似但不完全相同的系統，最后真正跑起來、真正被大規模使用的，不是你的東西。

所以當時一個核心判斷就是：如果 Google 只是繼續發白皮書，而不把東西做成一個別人真的能跑、能部署、能用的系統，那就不可能真正站在技術演進的駕駛位上。

再往下，就是為什么會是容器，而不是繼續圍繞虛擬機做文章。我們的判斷是，隨著軟件越來越成為關鍵基礎設施，大家一定會需要一種“自動駕駛”式的系統去管理應用。我們在 Google 內部已經很清楚，想把復雜軟件穩定跑起來，不能只靠人盯著，必須有系統幫你處理部署、調度、恢復這些事。這個需求不是可有可無，而是軟件復雜度走到一定階段后，一定會出現的東西。

真正最有意思的，是最后那個問題：為什么一定要開源？

很多人會說，你已經說服我這東西值得做了，那為什么不把它做成 Google Cloud 獨占的能力？這樣不是更有商業價值嗎？

可我們的判斷恰恰相反。因為如果你把它做成一個只在自己平臺上能用的東西，你反而贏不了。這個世界上還有很多用戶不在你的平臺上，他們在別的云上，也可能在本地機房里。如果你把這些人全擋在外面，他們不會等你，他們只會自己再做一個替代品。

開源生態之所以經常能贏，就是因為它能在更多地方運行。Linux 為什么能贏？很重要的一點，就是它可以去任何地方。對 Google Cloud 來說，如果你本來就不是市場第一，就更不能把這種東西做成封閉武器。你得讓所有人都能用它，再確保它在你的平臺上最好用。這樣即便別人不在你的平臺上，他們也會先聽你怎么定義問題、怎么講這個方向。

說得再直接一點：反正這個世界一定會出現一個開源版本。問題只是，這個開源版本到底是你做，還是別人做。

Q：所以從商業上說，Google 當時是想借 Kubernetes 改變云計算的競爭格局？

Brendan Burns：對，這是很重要的一部分。

如果市場上已經有人把虛擬機這套東西做成主流，而你能講出的故事只是“我們也有一套類似的，只是在某些地方更好一點”，那其實很難。你會一直活在別人的敘事里，一直在追別人的尾燈。

但如果你定義了一塊新戰場，情況就完全不一樣了。你不再只是追趕別人，而是開始由你來組織問題、組織語言。即便別人最后沒有直接跑在你的平臺上，他們也會先把注意力放到你這里，因為這個方向是你先講出來、先做出來的。

這種“話語權”很難量化，但它非常重要。它改變的是整個市場里誰在定義未來，誰在主導敘事。

當然，今天回頭看，Google Cloud 也沒有因為 Kubernetes 一下子變成市場第一，所以你不能把這件事講成一個簡單的商業勝利故事。但 Kubernetes 的確把 Google 放到了云原生時代最核心的話語位置上，這一點我覺得沒什么可爭議的。

Q：你們最早做出來的那個 demo，到底是什么樣子？

Brendan Burns：其實非常簡單。

大概就是一個最基礎的控制界面，能把容器部署出去，能把它分發到幾臺機器上，也能做一點很基礎的負載均衡。比如你訪問同一個入口，它會告訴你“我是副本 1”，刷新一下可能又變成“我是副本 3”，借這個讓你看到，它確實已經被復制并且分散到不同機器上了。

另外還有很基礎的健康檢查。你把進程殺掉，它能重新拉起來。再加上一個很初級的版本升級演示，能從 v1 切到 v2。差不多就是這些。

今天回頭看，這當然很原始，談不上什么完整產品。但對說服別人來說已經夠了。因為那不是一頁 PPT，也不是一份概念文檔，而是一個真實能跑起來的東西。

一個不到一周做出的 demo，后來改寫了云計算

Q：這個最初的 MVP，花了多久做出來？

Brendan Burns：不到一周吧，大概四五天。

當然，那真的是一個“能省的都省了”的版本。所有能走的捷徑都走了。很多底層能力也不是從零開始自己造，而是盡量借助現成的開源項目，把能拿來的東西拿來，再用一些 glue code 把它們粘起來，先讓系統具備基本的樣子。

我過去一直比較擅長的一件事，就是看怎么把已有的開源組件整合成一個新的系統。這種能力在 Kubernetes 最早那個階段特別關鍵。因為早期原型的價值，從來不是優雅，而是盡快讓別人看到：這件事是成立的，是跑得起來的。

Q：你當時不是也有自己的正式工作嗎？這種項目怎么騰出時間做？

Brendan Burns：我不會說自己把原來的工作完全扔了，但在那么短的時間尺度里，其實是可以挪出空間的。

我一直有一句有點“危險”的建議：我相信，大多數人都能從自己的工作里“藏出”大概 10% 的精力，而不被管理層真正察覺。

我的意思不是讓人偷懶，而是說，在大多數組織里，你其實總能保留一點點自由度，去做一些沒人明確讓你做、但你自己覺得重要的事。很多真正有影響力的想法，都是從這種空間里長出來的。

當然，這背后也有一個前提：你得接受失敗。

你去做這種 side project，很多時候不會成功。你可能投入了時間，最后什么都沒發生；你也可能因為把精力押在一件不確定的事上，而少做了一些更容易被看見、被評價的工作。你得接受這種風險，接受“試五次，成一次，但那一次的回報可能遠遠大于前面四次”的邏輯。

有些人適合這樣做，有些人不適合，這都很正常。

還有一個更直接、也更現實的事實是，很多人會說自己沒有時間做這些額外項目，但他們一周里很可能還是會花十幾個小時打游戲、刷 YouTube、看 Netflix。那最后其實不是有沒有時間的問題，而是你愿不愿意為了自己真正相信的事，放棄什么。

我不是那種鼓吹天天熬夜工作的人，但如果你真的覺得某件事重要，那有時候就意味著，你會在一段時間里少看點視頻，少做點別的娛樂。

Q：所以你的方法不是先寫文檔爭取許可，而是先把東西做出來？

Brendan Burns：對，差不多就是這樣。

很多事情很難靠文檔解釋清楚。你可以寫一份策略說明，也可以做一套 PowerPoint，但真正有效的方式，往往還是先拿出一個能跑的東西。只要它開始運行，討論的性質就會發生變化。

如果你什么都還沒做，管理層面對的問題是：要不要把時間和資源押給這件事。但如果你已經把東西做出來了，哪怕還很粗糙，問題就會變成：這個東西值不值得繼續推進、值不值得發布。

這兩種討論，完全不是一回事。

前者討論的是資源分配，后者討論的是這個想法本身是不是成立。對很多新項目來說，從前一種問題切換到后一種問題，本身就是一個決定性的進展。

當然，這里面依然有失敗風險。你可能花了時間把東西做出來，最后大家并不買賬。但如果你要做這種事，就得把這一點一起吞下去。你不能只接受成功的可能性，卻不接受失敗的代價。

Brendan Burns 的工程方法論，其實比 Kubernetes 本身更值錢

Q：從那個原型，到真正能讓別人拿來試用，中間隔了多久？

Brendan Burns：大概半年。

從一個非常 hacky 的原型，到一個我們覺得別人真的可以拿去嘗試的系統，中間還有大量基礎工作要補。很多看起來不起眼的細節，最后都得一項項做扎實。

但那個階段其實也很珍貴。因為你幾乎是在一個“干凈房間”里重做一套系統。很多后來加入的人，本來就在別的地方做過類似系統，腦子里早就積累了一堆“如果讓我重來一次，我會怎么設計”的想法。

可現實世界里，很少有工程師真的能得到這種機會。

更多時候，你接手的是一個已經上線、有大量用戶、有既有包袱的系統。你每天都在修 bug、兼容歷史問題、給舊設計打補丁。真正從零開始、在歷史債務相對少的情況下重建一套系統，是工程職業里非常稀缺的時刻。Kubernetes 早期恰好有這樣一個窗口。

Q：今天很多工程師聽這種故事，第一反應可能是：這畢竟是 Google，我在現實里哪有這樣的空間？

Brendan Burns：組織環境當然會有差異，但這里面也有一個個人選擇的問題。

很多人會把“沒有空間”理解成一個絕對條件，可現實更像是：空間很小，風險很高，而且沒有人會保證你做的事一定值得。你得自己判斷，自己下注，自己承擔不成的后果。

而且從職業發展上看，越往上走，這種能力反而越重要。因為在更高層級里，很少還有人會把一個足夠讓你完成躍遷的項目，包裝好、定義好、直接交到你手上。更多時候，真正重要的項目，是你自己看到、自己提煉、自己把它推出來的。

從這個角度看，所謂 side project，不只是“業余愛好”，它其實也是在訓練一種更主動的工程視角和職業能力。

K8s 也會死，只是死法可能和你想的不一樣

Q：Kubernetes 今天已經成了事實標準，它會不會也有自己的上限？

Brendan Burns：當然會有，但關鍵在于你怎么理解這個“上限”。

Kubernetes 的很多組件，本質上都可以橫向擴展。請求變多了，可以加 API Server；調度壓力大了，可以加調度器。很多部分都可以通過 scale out 來解決。

真正更難的，還是底層存儲層。因為在 Kubernetes 的架構里，大量狀態最終都會回到那里，真正不那么容易無限擴展的，也往往是這一層。今天大家熟悉的是 etcd，如果未來規模繼續往上推一個數量級，就得重新回答：它還能不能承受？還是說，需要一個保留相同核心特性、但擴展能力更強的方案來替代它？

我不認為 Kubernetes 在設計上存在一個天然寫死的天花板，阻止它繼續擴展。但系統一旦跨過一個數量級，問題就會遷移。原先最顯眼的瓶頸，可能突然變得不再重要，新的瓶頸會在別的地方浮出來。你原先受制于 CPU，后來可能變成受制于網絡；你原先受制于內存，后來可能變成受制于存儲。每跨過一個數量級，真正的問題都會移動。

Q：你說過一句話，軟件的宿命是死亡。那 Kubernetes 也會死嗎？

Brendan Burns：我完全認同這句話。

不過更完整的說法其實是：你最好別愛上自己的軟件，因為軟件不可避免的軌跡就是死亡。真正想表達的是，不要因為“這是我寫的”就舍不得放手。當它該被替代的時候，你就應該愿意把它扔掉。

從行業歷史來看，這幾乎是普遍規律。哪怕在 Kubernetes 內部，我當年寫的很多代碼，后來也已經被重寫很多次了。

至于 Kubernetes 會怎么“死”，未必一定是突然被另一個新系統徹底替代。有時候，一個系統并不會真的消失，而是會變得越來越底層、越來越隱形。就像今天 Linux 還在，但大多數人不會天天討論 Linux；處理器架構也還在，但不是所有開發者都時刻盯著它。

Kubernetes 也可能走向這種狀態：它還在，只是被更上層的系統蓋住了，被新的交互方式包起來了，最后人們越來越少直接感知它。

尤其在 AI 時代，很多注意力已經轉向模型、推理框架和應用接口，Kubernetes 可能慢慢退到底層，成為那個默認存在、但不再是主角的能力。

當然，如果把時間拉到足夠長，比如一百年后，我會非常驚訝 Kubernetes 還能原封不動地存在。技術世界變化太快了，很多今天看起來堅固的東西，幾年后就可能開始松動。未來最大的問題，從來不是你沒預測到變化，而是變化來得比你想象更快，或者根本不是你以為的那個方向。

關鍵是“記好筆記”

Q：你怎么看讀 PhD 這件事？很多人會糾結到底值不值。

Brendan Burns：這是別人最常問我的問題之一。

如果只從職業回報率來看，我可以講一個很現實的故事。我后來在同一家公司里遇到過一個本科同學。我們同年畢業，他去創業、進工業界，我去讀了 PhD，后來又回到工業界。結果我們最后在公司的層級是一樣的。

所以如果你問我，讀 PhD 會不會讓你在職業發展上顯著領先，我的答案大概是：未必。很多時候，其實差別沒那么大。

但如果反過來問，這段經歷值不值，我又會說：對我來說值，因為我玩得很開心，而且學到了很多非常有用的能力。

比如寫作和表達。博士訓練和導師對我的影響，讓我學會了怎么把一個復雜想法寫清楚、講清楚。后來 Kubernetes 早期那段時間，我們花了很久去推動、去說服、去爭取內部支持，這種能力其實非常重要。

另外，我后來還做過幾年教授。給完全不懂計算機的人上課，會逼著你去思考：你到底該怎么把一個復雜系統講到別人能懂。Kubernetes 早期也一樣，很多人會問：什么是容器？什么是 orchestration？我為什么需要它？這些問題都不是你把代碼寫出來就自動解決了的，你必須會教，必須會解釋。

所以如果你問我，我會說：PhD 不一定讓你在頭銜上更快領先，但它可能會給你一些長期非常有價值的能力。

Q：年輕工程師最常問你的另一個問題是什么？

Brendan Burns：另一個很常見的問題是：我到底該學什么？

比如現在 AI 很熱，但有些人自己更喜歡系統，就會來問我：那我是不是應該放棄系統去學 AI？我的回答通常是，我沒那么在乎你學的具體是什么，我更在乎你是不是在持續學習。

如果你對 AI 根本沒熱情，只因為它熱門就硬學，那你多半也學不好。反過來，如果你真的喜歡系統，你會投入更多時間和注意力進去，而這種持續投入更有可能轉化成真正的能力。行業也永遠不會不需要優秀的系統工程師。

我能感受到，很多年輕人特別害怕“選錯方向”。但說實話，我自己從來沒有一條嚴密的人生規劃。我一直都是看什么東西有意思、有價值，就去追。

當然，這種方式也可能有風險，但我也想提醒大家：很多你事后覺得是在繞路的經歷，最后恰恰可能變成最重要的養分。只要你一直在學，通常就不會太差。

Q：有沒有哪本書，對你的職業影響特別大？

Brendan Burns：如果是在工程師階段，對我影響很大的一本書是《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是大家熟悉的 GoF《設計模式》。

后來隨著角色變化，開始帶更大的團隊，我會更推薦另外兩本：一本是《Leadership on the Line》，另一本是《The Five Dysfunctions of a Team》。

前者更偏領導力，后者更偏團隊協作。大致可以這么理解：如果你現在主要還是工程師，先讀《設計模式》；如果你已經開始做管理或者組織領導，后兩本會更有幫助。

Q：如果回到剛大學畢業的時候，你會給當時的自己什么建議？

Brendan Burns：記更好的筆記。

我一直覺得，Kubernetes 這一路的經歷，其實完全值得寫成一本書，甚至能寫出一篇很好的商業案例。但問題是，我當年沒有留下足夠完整的記錄。

代碼當然還在，但真正容易消失的，往往不是代碼，而是那些關鍵時刻的討論、伙伴之間的拉扯、組織內部的推動、人與人之間的判斷和博弈。這些我現在還記得一部分，但已經記不全了。

如果當年能留下更完整的筆記，今天回頭看，一定會很有價值。

原視頻鏈接：youtu.be/FKijpCEH9D8

（投稿或尋求報道：zhanghy@csdn.net）

"48 小時，與 50+ 位大廠技術決策者，共探 AI 落地真路徑"

由 CSDN&奇點智能研究院聯合舉辦的「全球機器學習技術大會」正式升級為「奇點智能技術大會」。

2026 奇點智能技術大會將于 4 月 17-18 日在上海環球港凱悅酒店正式召開，大會聚焦大模型技術演進、智能體系統工程、OpenClaw 生態實踐及 AI 行業落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團等頭部企業的 50+ 位技術決策者分享實戰案例。旨在幫助技術管理者與一線 AI 落地人員規避選型風險、降低試錯成本、獲取可復用的工程方法論，真正實現 AI 技術的規模化落地與商業價值轉化。

這不僅是一場技術的盛宴，更是決策者把握 2026 AI 拐點的戰略機會。