本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 生日快樂。哦，你將去往何方！
親愛的 K8s，
你才一歲，真的讓人難以置信——你成長得如此之快。在你一歲生日之際，我想寫一篇小短文，談談你誕生時我為何如此激動，為何我如此幸運能成為撫養你成長的團隊一員，以及我為何迫不及待地想看到你繼續成長！
——Justin
你起步於一個出色的基礎——良好的宣告式功能，圍繞著一個擁有明確模式的堅實 API 構建，並具備了我們能夠向前發展的機制。果不其然，在你誕生後的第一年，你成長得如此迅速：自動擴縮、HTTP 負載均衡支援（Ingress）、對包括叢集資料庫在內的永續性工作負載的支援（PetSets）。你結交了更多的雲朋友（歡迎 Azure 和 OpenStack 加入大家庭），甚至開始跨區域和叢集（Federation）。而這些僅僅是其中一些最顯著的變化——你那大腦裡發生的更多事情不勝列舉！
我認為你所做的一切都保持如此開放，真是太棒了——無論好壞，你似乎把所有東西都寫在 GitHub 上。我想我們都在這個過程中學到了很多，比如工程師提出擴縮宣告的危險，這些宣告隨後會與那些沒有相同精確度和嚴謹性框架的宣告進行權衡。但我為你感到自豪的是，你選擇不降低自己的標準，而是迎難而上，跑得更快——這可能不是最現實的方法，但卻是移山唯一的途徑！
然而，不知何故，你成功避免了許多其他開源軟體，尤其是在專案變大、開發人員更多地投入其中而不是直接使用它時，所陷入的常見死衚衕。你是如何做到的？有一個大概是杜撰的故事，講的是一位 IBM 員工犯了一個大錯，被召見大老闆，以為自己會被解僱，結果卻被告知：“我們剛剛花了數百萬美元培訓你。我們為什麼要解僱你？”。儘管谷歌（以及 Redhat 和其他公司）在你身上投入了大量資金，我有時想知道我們避免的錯誤是否價值更高。有一個非常開放的開發過程，但有時也會有一個“預言家”，透過告訴我們如果我們做出某個特定的設計決策，兩年後會發生什麼來糾正方向。這樣的“家長”你大概應該聽從！
所以，儘管你才一歲，但你真的擁有一個古老的靈魂。我只是眾多撫養你的人之一，但能與那些構建了這些令人難以置信的系統並擁有所有這些領域知識的人一起工作，對我來說是一次美妙的學習經歷。然而，因為我們從零開始（而不是採用現有的 Borg 程式碼），我們處於相同的水平，仍然可以就如何撫養你進行真正的討論。好吧，至少我們能達到的水平是如此接近，但值得稱讚的是，他們都太好了，從不提及此事！
如果我必須挑選出那些傑出人士所做的兩項明智決定，那將是：
- 標籤和選擇器為我們提供了宣告式的“指標”，因此我們可以說我們“想要”什麼，而不是直接列出具體事物。這是你能夠攀登高峰的秘密；不是透過命名每一個步驟，而是說“再多一千個像第一個那樣的步驟”。
- 控制器是狀態同步器：我們指定目標，而你的控制器將不知疲倦地工作，使系統達到該狀態。它們透過強型別 API 基礎工作，並在整個程式碼中被使用，因此 Kubernetes 更像是一百個小程式組成的集合，而不是一個大程式。僅靠技術上擴充套件到數千個節點是不夠的；專案還必須擴充套件到數千個開發人員和功能；而控制器幫助我們實現這一目標。
所以我們繼續前行！我們將替換這些控制器並構建更多，API 基礎使我們能夠構建任何可以透過這種方式表達的事物——大多數東西都只差一個標籤或註解！但你的思想將不受語言的限制：透過第三方資源，你可以表達你選擇的任何內容。現在我們可以在不構建 Kubernetes 內部的情況下構建 Kubernetes，創造出與 Kubernetes 本身一樣重要的事物。許多最近的新增，如 Ingress、DNS 整合、自動擴縮和網路策略，都是透過這種方式完成或可以完成的。最終，很難想象沒有這些功能之前的你，但明天的標準功能可以從今天開始，沒有障礙或看門人，甚至可能只針對一個受眾。
因此，我期待看到 Kubernetes 核心之外的更多增長。我們必須經歷這些階段；從需要在 Kubernetes 核心中發生的事情開始——比如用部署替換複製控制器。現在我們開始構建不需要核心更改的東西。但我們仍然在將基礎設施與應用程式分開討論。接下來才會變得真正有趣：當我們開始構建依賴 Kubernetes API 的應用程式時。我們一直有使用 Kubernetes API 進行自組裝的 Cassandra 示例，但我們還沒有真正開始更廣泛地探索這一點。就像 S3 API 改變了我們構建記住事物的方式一樣，我認為 k8s API 將改變我們構建思考事物的方式。
所以我期待你的第二個生日：我可以嘗試預測你那時會是什麼樣子，但我知道你將超越我所能想象的最出奇的東西。哦，你將去往何方！