本文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 生日快樂。喔，您將去的地方！
親愛的 K8s，
難以置信您才一歲 - 您長得真快。在您一歲生日之際，我想寫一小段話，說明為何您出生時我如此興奮、為何我感到幸運能成為撫養您長大的團隊的一份子，以及為何我渴望看著您繼續成長！
--Justin
您從一個優秀的基礎開始 - 良好的宣告式功能，圍繞著具有明確定義的架構和機制的穩固 API 构建，以便我們可以向前發展。果然，在您的第一年裡，您成長得如此之快：自動縮放、HTTP 負載平衡支援 (Ingress)、對持久性工作負載（包括叢集資料庫 (PetSets)）的支援。您與更多雲端交了朋友（歡迎 Azure 和 OpenStack 加入這個大家庭），甚至開始跨越區域和叢集（聯邦）。而這些只是一些最明顯的變化 - 在您的大腦內部發生了如此多的事情！
我認為您在所做的一切事情中都保持如此開放的態度真是太好了 - 無論好壞，您似乎都將一切都寫在 GitHub 上。我認為我們都在這方面學到了很多，例如工程師做出擴展聲明的風險，然後將這些聲明與在沒有完全相同的精確度和嚴謹框架下做出的聲明進行權衡。但我很自豪您選擇不降低您的標準，而是迎接挑戰並反而跑得更快 - 這可能不是最現實的方法，但這是移動山的唯一方法！
然而，不知何故，您設法避免了許多其他開源軟體陷入的常見死胡同，特別是當這些專案變得更大，開發人員最終花在開發上的時間比直接使用它的時間更多時。您是如何做到的？有一個可能是虛構的故事，一位 IBM 員工犯了一個巨大的錯誤，被召見與大老闆會面，預計會被解僱，結果卻被告知「我們剛剛花了數百萬美元培訓您。我們為什麼要解僱您？」。儘管 Google（以及 Redhat 和其他公司）對您投入了大量資金，但我有時想知道我們正在避免的錯誤是否可能更有價值。有一個非常開放的開發過程，但也有一個「預言家」，有時會透過告訴我們如果我們做出特定的設計決策，兩年後會發生什麼來糾正方向。這是一位您應該聽從的家長！
因此，儘管您只有一歲，但您真的有一個 老靈魂。我只是 撫養您長大的許多人 之一，但能夠與構建這些令人難以置信的系統並擁有所有這些領域知識的人一起工作對我來說是一次美好的學習經歷。然而，由於我們從頭開始（而不是採用現有的 Borg 代碼），我們處於相同的水平，並且仍然可以就如何撫養您進行真正的討論。嗯，至少盡可能接近相同的水平，但值得稱讚的是，他們都太好了，從未提及此事！
如果我要挑選那些傑出人士做出的兩個明智決定
- 標籤和選擇器為我們提供了宣告式「指標」，因此我們可以說「為什麼」我們想要這些東西，而不是直接列出這些東西。這是您可以擴展到 很高的高度 的秘訣；不是透過命名每個步驟，而是說「再執行一千個像第一個步驟一樣的步驟」。
- 控制器是狀態同步器：我們指定目標，您的控制器將不知疲倦地工作以使系統達到該狀態。它們透過強型別的 API 基礎工作，並在整個程式碼中使用，因此 Kubernetes 更像是一組一百個小型程式而不是一個大型程式。僅在技術上擴展到數千個節點是不夠的；專案還必須擴展到數千名開發人員和功能；而控制器可以幫助我們實現這一目標。
我們將繼續前進！我們將替換這些控制器並在此基礎上構建更多，而 API 基礎讓我們可以構建我們可以用這種方式表達的任何東西 - 大多數東西只是一個標籤或註釋！但您的想法不會受到語言的限制：透過第三方資源，您可以表達您選擇的任何內容。現在我們可以在不構建 Kubernetes 的情況下構建 Kubernetes，創建感覺與 Kubernetes 其他任何部分一樣的東西。最近的許多新增功能，例如 ingress、DNS 整合、自動縮放和網路策略，都是以這種方式完成或可以完成的。最終，很難想像在沒有這些東西之前您的樣子，但明天的標準功能可以從今天開始，沒有障礙或守門員，甚至可能是為了單一受眾。
因此，我期待看到越來越多的成長發生在離 Kubernetes 核心越來越遠的地方。我們必須經歷這些階段；從需要在 Kubernetes 核心中發生的事情開始 - 例如用部署替換複製控制器。現在我們開始構建不需要核心變更的東西。但我們仍然在將基礎設施與應用程式分開討論。接下來發生的事情才真正有趣：當我們開始構建依賴 Kubernetes API 的應用程式時。我們一直有 Cassandra 範例使用 Kubernetes API 進行自我組裝，但我們還沒有真正開始更廣泛地探索這一點。就像 S3 API 改變了我們構建記憶事物的方式一樣，我認為 k8s API 將改變我們構建思考事物的方式。
因此，我期待您的兩歲生日：我可以嘗試預測那時您會是什麼樣子，但我知道您會超越我能想像到的最膽大的事情。喔，您將去的地方！