如果說以“不斷提升插件能力和可擴展能力”的 “基礎(chǔ)設(shè)施開源項目民主化”進程是 Kubernetes 在2017-2018年的核心主題的話，那么在2019年，這個技術(shù)社區(qū)的發(fā)展脈絡(luò)又是怎樣的呢?

今天，阿里云高級技術(shù)專家張磊將從 Kubernetes 1.14 這個承前啟后的版本聊起，一窺技術(shù)社區(qū)的演進方向。

Kubernetes 1.14 正式發(fā)布已經(jīng)過去了一段時間，相信你已經(jīng)從不同渠道看過了各種版本的解讀。

不過，相比于代碼 Release，馬上就要迎來5周歲生日的 Kubernetes 項目接下來如何演進，其實也是一個讓人著迷的話題。而作為一個日趨成熟的開源生態(tài)，Kubernetes 項目每三個月一次的正式發(fā)布，其實正是這個高速發(fā)展的技術(shù)社區(qū)不斷向前演進的過程中留下的扎實腳印。

Windows 生態(tài)成為 Kubernetes 項目的一等公民

Kubernetes 對 Windows 生態(tài)的支持，自從這個項目發(fā)布起就被提上了日程。不過，作為一個純粹的 Linux 技術(shù)棧支撐的基礎(chǔ)設(shè)施開源項目，Windows 節(jié)點以及 Windows 容器支持真正取得實質(zhì)性進展，還是要從 Kubernetes 項目的插件和可擴展能力在1.6版本后逐漸成熟之后才慢慢步入了正軌。這也很容易理解，Windows 體系與目前主流容器技術(shù)棧有著本質(zhì)性的差異，這就要求 Kubernetes 項目必須能夠提供更高層次的抽象和可擴展能力以支持兩種迥然不同的技術(shù)棧，并且同現(xiàn)有的Kubernetes 生態(tài)比如 CNI 和 CSI 完成對接。這部分工作的復(fù)雜度和工作量，也是 Windows Node 的生產(chǎn)可用從1.13延期到1.14的主要原因。

而在這次1.14的發(fā)布中，Kubernetes 的 Pod，Service，應(yīng)用編排，CNI 網(wǎng)絡(luò)等絕大多數(shù)核心能力都已經(jīng)在 Windows 節(jié)點上得到了支持。此外，包括自定義監(jiān)控指標、水平擴展、搶占和優(yōu)先級調(diào)度等很多進階功能也都在 Windows 上得以實現(xiàn)。

目前，尚不能被支持的功能基本上都是在 Windows 上暫時無法實現(xiàn)的語義比如 Host Network 以及其它 Linux 內(nèi)核專屬的資源和權(quán)限定義方式等?？梢钥吹剑琄ubernetes 這次發(fā)布對 Windows 節(jié)點和 Windows 容器的支持，較之前相比有了巨大提升，完成度非常高，確實對得起 “GA”這個具備承諾意味的發(fā)布用語。

而國內(nèi)外公共云提供商比如阿里云容器服務(wù)(ACK)也已經(jīng)于近期已經(jīng)推出了 Windows Container 的支持，提供了 Linux/Windows 應(yīng)用混合部署的統(tǒng)一管理能力，再一次印證了這次發(fā)布的可用度。

不難看到，公共云提供商(比如本次Windows 支持GA背后的微軟云團隊)作為 CNCF社區(qū)的主要推動方之一，實際上一直在整個云原生技術(shù)生態(tài)中發(fā)揮著巨大的作用，逐步促成了將像 Windows 支持這樣的實際企業(yè)用戶訴求帶給了一個高速發(fā)展的、完全以 Linux 技術(shù)棧為核心的基礎(chǔ)設(shè)施項目。而在未來的發(fā)展中，諸如此類的來自于公共云提供商的輸入，將會繼續(xù)在 Kubernetes 項目發(fā)展的過程中扮演至關(guān)重要的角色，這也會成為更多的企業(yè)用戶能夠從云原生技術(shù)生態(tài)中獲益的一個重要途徑。這一點，將會繼續(xù)成為 Kubernetes 項目與其他基礎(chǔ)設(shè)施開源項目的根本不同。

Kubernetes 原生的應(yīng)用管理能力嶄露頭角

在長期一段時間里，Kubernetes 的應(yīng)用管理都是由 Helm 這樣的第三方項目或者上層 PaaS 來完成的。不過，在1.14之后，Kubernetes 項目本身開始具備了原生的應(yīng)用管理能力，這其中最重要的一個功能，就是 Kustomize。

Kustomize 允許用戶以一個應(yīng)用描述文件 (YAML 文件)為基礎(chǔ)(Base YAML)，然后通過 Overlay 的方式生成最終部署應(yīng)用所需的描述文件，而不是像 Helm 那樣只提供應(yīng)用描述文件模板，然后通過字符替換(Templating)的方式來進行定制化。

而與此同時，其他用戶可以完全不受影響地使用任何一個 Base YAML 或者任何一層生成出來的 YAML 。這使得每一個用戶都可以通過類似 fork/modify/rebase 這樣 Git 風格的流程來管理海量的應(yīng)用描述文件。這種 PATCH 的思想跟 Docker 鏡像是非常相似的，它可以規(guī)避“字符替換”對應(yīng)用描述文件的入侵，也不需要用戶學習額外的 DSL 語法(比如 Lua)。

更為重要的是，上述PATCH 的思想，跟 Kubernetes 項目強調(diào)的聲明式 API 是完全匹配的，整個使用體驗跟 Kubernetes API 本身完全一致，沒有割裂感(大家可以思考一下為什么 PATCH 才是聲明式 API 的精髓)。

在1.14發(fā)布中，Kustomize 功能已經(jīng)成為了 kubectl 的一個內(nèi)置命令，這使得用戶使用 Kubernetes 的聲明式 API來直接在云端管理、修改和部署海量的應(yīng)用成為了可能。并且，kubectl 本身的插件機制也在1.14中得到了大量完善，使得 kubectl 結(jié)合各種客戶端插件已經(jīng)具備成為應(yīng)用管理工具的潛在能力。而在這樣的演進路線下，Kubernetes 項目對應(yīng)用以及應(yīng)用管理的定義也開始清晰了起來，我們可以用如下一幅示意圖來簡單描述：

??

在這個 Kubernetes 原生的應(yīng)用管理體系中，應(yīng)用描述文件(YAML 文件)居于核心位置。一份應(yīng)用描述文件，實際上是多個 Kubernetes API 對象的組合，共同定義了這個部署這個應(yīng)用所需的資源編排和服務(wù)編排內(nèi)容。一旦這樣一個描述文件提交給Kubernetes ，那么接下來它就會通過控制器模式來保證整個集群里的狀態(tài)與該描述文件的定義完全一致。

這些描述文件的來源，則來自于上層框架或者用戶的產(chǎn)出。更為重要的是，所有對應(yīng)用的操作，都應(yīng)該通過聲明式 API 對該文件進行 Create、Patch 和 Delete 操作來完成，進而觸發(fā) Kubernetes 的控制器模型執(zhí)行預(yù)定義的編排動作。

不難看到，在這個模型中，Helm 和 Kustomize 其實定義了兩種不同的應(yīng)用描述文件的產(chǎn)出路徑和用戶體驗，也代表了兩種同 Kubernetes API 不同的耦合度和抽象程度：一個自成體系，一個則融入到了 Kubernetes的設(shè)計理念當中。在1.14發(fā)布之后，Kubernetes 社區(qū)當前正在探索的這種應(yīng)用管理體系效果如何，我們不妨拭目以待。

大規(guī)模場景下的性能優(yōu)化工作逐漸提上日程

熟悉 Kubernetes 項目的很多參與者可能都知道，在過去一段時間，Kubernetes 社區(qū)對于大規(guī)模場景下的性能優(yōu)化工作的優(yōu)先級大多不會非常高。這里的原因也比較容易理解，在一個基礎(chǔ)設(shè)施開源項目發(fā)展的早期，擴大生態(tài)和完善功能相比于支持更大的集群來說往往要更重要一些。

但在 Kubernetes 的主干功能日趨穩(wěn)定之后，社區(qū)一定會開始更多地關(guān)注大規(guī)模場景下 Kubernetes 項目會暴露出來的各種各樣的問題，這其實依然容易理解：中小規(guī)模的用戶固然是整個項目取得生態(tài)成功的根本，但是通過 Kubernetes 這條路徑讓更多的沃爾瑪、星巴克、國內(nèi)外的技術(shù)獨角獸們成為云原生技術(shù)的受益者，進而成為公共云上的規(guī)模性用戶，一定是 Kubernetes 社區(qū)要重點考慮的發(fā)展方向。

當然，作為一個天然處于“被集成”位置的基礎(chǔ)設(shè)施項目，Kubernetes 進行性能提升的主要方向，一定優(yōu)先關(guān)注于與上層使用者關(guān)系最為緊密的 API 層以及客戶端使用場景。當然，這也與 Kubernetes 項目的架構(gòu)關(guān)系緊密：聲明式 API 的設(shè)計圍繞著以 etcd 為核心的配置管理機制，使得 Kubernetes 項目天生就是一個重 API 層而輕調(diào)度的分布式系統(tǒng)。這也意味著當需要管理的配置信息(即：API 對象)數(shù)量巨大時，這一層也是最有可能的暴露出性能問題的領(lǐng)域。

所以，在 Kubernetes v1.14中，社區(qū)首先從面向最終用戶的角度做出了很多優(yōu)化，比如： kubectl 對 API 對象的遍歷行為進行了大量的并行化工作。這種看似微小的修改在大規(guī)模場景下對 kubectl 使用者帶來的性能提升體驗，卻是非常顯著的。

當然，最重要的工作，還是發(fā)生在 APIServer 本身的性能優(yōu)化上。比如，Kubernetes 的 Aggregated API 允許開發(fā)人員編寫一個自定義服務(wù)，并把這個服務(wù)注冊到 k8s 的 API 里面像原生 API 一樣使用。但是在這個情況下，APIServer 會將用戶自定義 API Spec 與原生的 API Spec 歸并起來，這是一個非常消耗CPU 的性能痛點。而在v1.14中，社區(qū)專門對這個操作的效率進行了細致的優(yōu)化，終極將APIServer 歸并 Spec 的性能提升了十倍以上。

除此之外，Kubernetes 項目性能提升的另一個重要方向，就是對 etcd 到 APIServer 之間的連接路徑的優(yōu)化和提升上。作為 Kubernetes 項目的配置中心，也是外部數(shù)據(jù)依賴，etcd 每一次提交操作的數(shù)據(jù)量和間隔大小，每一個連接的請求和響應(yīng)周期，都有可能對最終 Kubernetes 項目在大規(guī)模場景下的性能表現(xiàn)產(chǎn)生影響。阿里巴巴的技術(shù)團隊在 etcd 項目的中一直在持續(xù)進行性能調(diào)優(yōu)與提升工作并已陸續(xù)發(fā)布在了 etcd 的新版本當中。這些內(nèi)容雖然不屬于 Kubernetes 1.14 發(fā)布的一部分，但同樣值得我們關(guān)注。

可擴展能力和項目穩(wěn)定性持續(xù)提升

除了上述幾個領(lǐng)域在本次發(fā)布后逐步成為核心領(lǐng)域之外，Kubernetes 項目在過往一直比較重視的幾個核心方向，比如，可擴展能力的提升，項目穩(wěn)定性等，依然是 Kubernetes 項目繼續(xù)演進的重要旋律。所以在 Kubernetes 1.14中，才會出現(xiàn)很多像“Pod Ready ++” 這樣將原本已經(jīng)成熟的系統(tǒng)特性進一步重構(gòu)成為可擴展接口的重要變更。在 Pod Ready ++ 正式發(fā)布后，Kubernetes 用戶只需要自己編寫一個外部控制器(Controller)就可以非常方便地自定義一個應(yīng)用從創(chuàng)建到最終可用(Ready)的標準到底是什么，而不是被強迫遵守 Kubernetes 項目已有的定義方法。這種能力，同樣是基礎(chǔ)設(shè)施開源項目“民主化”的重要體現(xiàn)。

總結(jié)

Kubernetes 1.14的發(fā)布，在這個日趨成熟穩(wěn)定的項目開源基礎(chǔ)設(shè)施項目的發(fā)展過程中有著重要的承前啟后的作用。所以我們會看到，Kubernetes 社區(qū)正在幾個以往并不太受關(guān)注的領(lǐng)域里開始持續(xù)發(fā)力，甚至有可能會進一步改變整個云原生社區(qū)在某些領(lǐng)域的發(fā)展方向。這種在日趨穩(wěn)定的發(fā)展歷程中不時透露出來的技術(shù)革新，也正是這個社區(qū)能夠持續(xù)令人興奮的關(guān)鍵所在。

而放眼當前的云計算生態(tài)，國外越來越多的大規(guī)模企業(yè)級用戶比如 Snapchat、Twitter 等都已經(jīng)開始了將自己的整套技術(shù)棧直接遷往以 Kubernetes 為基礎(chǔ)的公共云服務(wù)上，這正好印證了“云原生”這個關(guān)鍵詞的本質(zhì)含義：在未來云的時代，軟件的開發(fā)、測試、發(fā)布、運維等完整的生命周期，都會基于云來進行。而所謂的“云原生”，其實正在通過一系列技術(shù)手段，為廣大開發(fā)者編制出了一幅能夠讓軟件天然的生長在云上、交付在云上，從而大程度地發(fā)揮出云的價值的技術(shù)藍圖。

更多關(guān)于云原生技術(shù)原理和實踐的內(nèi)容，歡迎點擊文末“閱讀原文”關(guān)注阿里云和CNCF 官方聯(lián)合開發(fā)的免費公開課《CNCF x Alibaba 云原生技術(shù)公開課》：業(yè)內(nèi)一線技術(shù)大咖為你剖析云原生技術(shù)核心原理與落地實踐，期待各位的學習與反饋。

參考資料：

??https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md??

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

??戳這里，看該作者更多好文??