從Kubernetes 1.14 發佈，看技術社區演進方向

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爲基礎的公有云服務上，這正好印證了「雲原生」這個關鍵詞的本質含義：在將來雲的時代，軟件的開發、測試、發佈、運維等完整的生命週期，都會基於雲來進行。而所謂的「雲原生」，其實正在經過一系列技術手段，爲廣大開發者編制出了一幅可以讓軟件自然的生長在雲上、交付在雲上，從而最大程度地發揮出雲的價值的技術藍圖。

更多關於雲原生技術原理和實踐的內容，歡迎關注阿里雲和CNCF 官方聯合開發的免費公開課《CNCF x Alibaba 雲原生技術公開課》。業內一線技術大咖爲你剖析雲原生技術核心原理與落地實踐，期待各位的學習與反饋： https://edu.aliyun.com/roadma...