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

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

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

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

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

Kubernetes 對(duì) Windows 生態(tài)的支持，自從這個(gè)項(xiàng)目發(fā)布起就被提上了日程。不過，作為一個(gè)純粹的 Linux 技術(shù)棧支撐的基礎(chǔ)設(shè)施開源項(xiàng)目，Windows 節(jié)點(diǎn)以及 Windows 容器支持真正取得實(shí)質(zhì)性進(jìn)展，還是要從 Kubernetes 項(xiàng)目的插件和可擴(kuò)展能力在1.6版本后逐漸成熟之后才慢慢步入了正軌。這也很容易理解，Windows 體系與目前主流容器技術(shù)棧有著本質(zhì)性的差異，這就要求 Kubernetes 項(xiàng)目必須能夠提供更高層次的抽象和可擴(kuò)展能力以支持兩種迥然不同的技術(shù)棧，并且同現(xiàn)有的Kubernetes 生態(tài)比如 CNI 和 CSI 完成對(duì)接。這部分工作的復(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é)點(diǎn)上得到了支持。此外，包括自定義監(jiān)控指標(biāo)、水平擴(kuò)展、搶占和優(yōu)先級(jí)調(diào)度等很多進(jìn)階功能也都在 Windows 上得以實(shí)現(xiàn)。

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

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

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

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

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

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

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

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

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

??

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

參考資料：

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

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

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