Kubernetes 1.14 正式釋出已經過去了一段時間，相信你已經從不同渠道看過了各種版本的解讀。
不過，相比於程式碼 Release，馬上就要迎來5週歲生日的Kubernetes 專案接下來如何演進，其實也是一個讓人著迷的話題。而作為一個日趨成熟的開源生態，Kubernetes 專案每三個月一次的正式釋出，其實正是這個高速發展的技術社群不斷向前演進的過程中留下的紮實腳印。
而如果說以“不斷提升外掛能力和可擴充套件能力”的 “基礎設施開源專案民主化”程式是Kubernetes在2017-2018年的核心主題的話，那麼在2019年，這個技術社群的發展脈絡又是怎樣的呢？
本篇文章，我們將從Kubernetes 1.14 這個承前啟後的釋出出發，一起來探索一下這個問題背後的技術本質。
Windows 生態成為 Kubernetes 專案的一等公民
Kubernetes 對 Windows 生態的支援，自從這個專案釋出起就被提上了日程。不過，作為一個純粹的 Linux 技術棧支撐的基礎設施開源專案，Windows 節點以及 Windows 容器支援真正取得實質性進展，還是要從Kubernetes 專案的外掛和可擴充套件能力在1.6版本後逐漸成熟之後才慢慢步入了正軌。這也很容易理解，Windows 體系與目前主流容器技術棧有著本質性的差異，這就要求Kubernetes專案必須能夠提供更高層次的抽象和可擴充套件能力以支援兩種迥然不同的技術棧，並且同現有的Kubernetes生態比如 CNI 和 CSI 完成對接。這部分工作的複雜度和工作量，也是 Windows Node的生產可用從1.13延期到1.14的主要原因。
而在這次1.14的釋出中，Kubernetes 的Pod，Service，應用編排，CNI 網路等絕大多數核心能力都已經在 Windows 節點上得到了支援。此外，包括自定義監控指標、水平擴充套件、搶佔和優先順序排程等很多進階功能也都在 Windows 上得以實現。目前，尚不能被支援的功能基本上都是在 Windows 上暫時無法實現的語義比如 Host Network以及其它Linux 核心專屬的資源和許可權定義方式等。可以看到，Kubernetes 這次釋出對 Windows節點和 Windows 容器的支援，較之前相比有了巨大提升，完成度非常高，確實對得起 “GA”這個具備承諾意味的釋出用語。而國內外公有云提供商比如阿里雲容器服務（ACK）也已經於近期已經推出了 Windows Container 的支援，提供了Linux/Windows應用混合部署的統一管理能力，再一次印證了這次釋出的可用度。
不難看到，公有云提供商（比如本次Windows 支援GA背後的微軟雲團隊）作為 CNCF社群的主要推動方之一，實際上一直在整個雲原生技術生態中發揮著巨大的作用，逐步促成了將像 Windows 支援這樣的實際企業使用者訴求帶給了一個高速發展的、完全以 Linux 技術棧為核心的基礎設施專案。而在未來的發展中，諸如此類的來自於公有云提供商的輸入，將會繼續在 Kubernetes 專案發展的過程中扮演至關重要的角色，這也會成為更多的企業使用者能夠從雲原生技術生態中獲益的一個重要途徑。這一點，將會繼續成為 Kubernetes 專案與其他基礎設施開源專案的最大不同。
Kubernetes 原生的應用管理能力嶄露頭角
在長期一段時間裡，Kubernetes 的應用管理都是由 Helm 這樣的第三方專案或者上層 PaaS 來完成的。不過，在1.14之後，Kubernetes 專案本身開始具備了原生的應用管理能力，這其中最重要的一個功能，就是 Kustomize。
Kustomize 允許使用者以一個應用描述檔案 （YAML 檔案）為基礎（Base YAML），然後通過 Overlay 的方式生成最終部署應用所需的描述檔案，而不是像 Helm 那樣只提供應用描述檔案模板，然後通過字元替換（Templating）的方式來進行定製化。
而與此同時，其他使用者可以完全不受影響的使用任何一個Base YAML 或者任何一層生成出來的 YAML 。這使得每一個使用者都可以通過類似fork/modify/rebase 這樣 Git 風格的流程來管理海量的應用描述檔案。這種 PATCH 的思想跟 Docker 映象是非常相似的，它可以規避“字元替換”對應用描述檔案的入侵，也不需要使用者學習額外的 DSL 語法（比如 Lua）。
更為重要的是，上述PATCH 的思想，跟 Kubernetes 專案強調的宣告式 API是完全匹配的，整個使用體驗跟 Kubernetes API 本身完全一致，沒有割裂感（大家可以思考一下為什麼 PATCH 才是宣告式API 的精髓）。
在1.14釋出中，Kustomize 功能已經成為了 kubectl 的一個內建命令，這使得使用者使用 Kubernetes 的宣告式 API來直接在雲端管理、修改和部署海量的應用成為了可能。並且，kubectl 本身的外掛機制也在1.14中得到了大量完善，使得 kubectl 結合各種客戶端外掛已經具備成為應用管理工具的潛在能力。而在這樣的演進路線下，Kubernetes 專案對應用以及應用管理的定義也開始清晰了起來，我們可以用如下一幅示意圖來簡單描述：
在這個 Kubernetes 原生的應用管理體系中，應用描述檔案（YAML 檔案）居於核心位置。一份應用描述檔案，實際上是多個 Kubernetes API 物件的組合，共同定義了這個部署這個應用所需的資源編排和服務編排內容。一旦這樣一個描述檔案提交給 Kubernetes ，那麼接下來它就會通過控制器模式來保證整個叢集裡的狀態與該描述檔案的定義完全一致。
這些描述檔案的來源，則來自於上層框架或者使用者的產出。更為重要的是，所有對應用的操作，都應該通過宣告式 API 對該檔案進行 Create、Patch 和 Delete 操作來完成，進而觸發 Kubernetes 的控制器模型執行預定義的編排動作。
不難看到，在這個模型中，Helm和 Kustomize 其實定義了兩種不同的應用描述檔案的產出路徑和使用者體驗，也代表了兩種同 Kubernetes API 不同的耦合度和抽象程度：一個自成體系，一個則融入到了 Kubernetes的設計理念當中。在1.14釋出之後，Kubernetes 社群當前正在探索的這種應用管理體系效果如何，我們不妨拭目以待。
大規模場景下的效能優化工作逐漸提上日程
熟悉 Kubernetes 專案的很多參與者可能都知道，在過去一段時間，Kubernetes 社群對於大規模場景下的效能優化工作的優先順序大多不會非常高。這裡的原因也比較容易理解，在一個基礎設施開源專案發展的早期，擴大生態和完善功能相比於支援更大的叢集來說往往要更重要一些。
但在 Kubernetes 的主幹功能日趨穩定之後，社群一定會開始更多的關注大規模場景下 Kubernetes 專案會暴露出來的各種各樣的問題，這其實依然容易理解：中小規模的使用者固然是整個專案取得生態成功的根本，但是通過 Kubernetes 這條路徑讓更多的沃爾瑪、星巴克、國內外的技術獨角獸們成為雲原生技術的受益者，進而成為公有云上的規模性使用者，一定是 Kubernetes 社群要重點考慮的發展方向。
當然，作為一個天然處於“被整合”位置的基礎設施專案，Kubernetes 進行效能提升的主要方向，一定優先關注於與上層使用者關係最為緊密的 API 層以及客戶端使用場景。當然，這也與 Kubernetes 專案的架構關係緊密：宣告式API 的設計圍繞著以 etcd 為核心的配置管理機制，使得 Kubernetes 專案天生就是一個重 API 層而輕排程的分散式系統。這也意味著當需要管理的配置資訊（即：API 物件）數量巨大時，這一層也是最有可能的暴露出效能問題的領域。
所以，在Kubernetes v1.14中，社群首先從面向終端使用者的角度做出了很多優化，比如：kubectl對 API 物件的遍歷行為進行了大量的並行化工作。這種看似微小的修改在大規模場景下對kubectl使用者帶來的效能提升體驗，卻是非常顯著的。
當然，最重要的工作，還是發生在 APIServer 本身的效能優化上。比如，Kubernetes 的 Aggregated API允許開發人員編寫一個自定義服務，並把這個服務註冊到k8s的 API 裡面像原生 API 一樣使用。但是在這個情況下，APIServer 會將使用者自定義 API Spec 與原生的 API Spec 歸併起來，這是一個非常消耗CPU 的效能痛點。而在v1.14中，社群專門對這個操作的效率進行了細緻的優化，最終極將APIServer 歸併 Spec 的效能提升了十倍以上。
除此之外，Kubernetes 專案效能提升的另一個重要方向，就是對 etcd 到 APIServer 之間的連線路徑的優化和提升上。作為 Kubernetes 專案的配置中心，也是唯一的外部資料依賴，etcd每一次提交操作的資料量和間隔大小，每一個連線的請求和響應週期，都有可能對最終Kubernetes 專案在大規模場景下的效能表現產生影響。阿里巴巴的技術團隊在etcd 專案的中一直在持續進行效能調優與提升工作並已陸續釋出在了 etcd 的最新版本當中。這些內容雖然不屬於 Kubernetes 1.14 釋出的一部分，但同樣值得我們關注。
可擴充套件能力和專案穩定性持續提升
除了上述幾個領域在本次釋出後逐步成為核心領域之外，Kubernetes 專案在過往一直比較重視的幾個核心方向，比如，可擴充套件能力的提升，專案穩定性等，依然是 Kubernetes 專案繼續演進的重要旋律。所以在Kubernetes 1.14中，才會出現很多像 “Pod Ready ++” 這樣將原本已經成熟的系統特性進一步重構成為可擴充套件介面的重要變更。在Pod Ready ++ 正式釋出後，Kubernetes 使用者只需要自己編寫一個外部控制器（Controller）就可以非常方便的自定義一個應用從建立到最終可用（Ready） 的標準到底是什麼，而不是被強迫遵守 Kubernetes 專案已有的定義方法。這種能力，同樣是基礎設施開源專案“民主化”的重要體現。
對於這些可擴充套件能力和專案穩定性提升技術細節的解讀，推薦你關注 Kubernetes 1.14 釋出技術解讀文章來做進一步瞭解，並最終按照這些特性對自己所在組設定的重要程度來定製的升級計劃。
總結
Kubernetes 1.14的釋出，在這個日趨成熟穩定的專案開源基礎設施專案的發展過程中有著重要的承前啟後的作用。所以我們會看到，Kubernetes 社群正在幾個以往並不太受關注的領域裡開始持續發力，甚至有可能會進一步改變整個雲原生社群在某些領域的發展方向。這種在日趨穩定的發展歷程中不時透露出來的技術革新，也正是這個社群能夠持續令人興奮的關鍵所在
而放眼當前的雲端計算生態，國外越來越多的大規模企業級使用者比如 Snapchat、Twitter等都已經開始了將自己的整套技術棧直接遷往以Kubernetes為基礎的公有云服務上，這正好印證了“雲原生”這個關鍵詞的本質含義：在未來雲的時代，軟體的開發、測試、釋出、運維等完整的生命週期，都會基於雲來進行。而所謂的“雲原生”，其實正在通過一系列技術手段，為廣大開發者編制出了一幅能夠讓軟體天然的生長在雲上、交付在雲上，從而最大程度地發揮出雲的價值的技術藍圖。
本文為雲棲社群原創內容，未經允許不得轉載。