建站
咨詢
售后
建站咨詢
新聞中心
如果說以“不斷提升插件能力和可擴展能力”的 “基礎設施開源項目民主化”進程是 Kubernetes 在2017-2018年的核心主題的話，那么在2019年，這個技術社區(qū)的發(fā)展脈絡又是怎樣的呢?
創(chuàng)新互聯(lián)服務項目包括鄢陵網站建設、鄢陵網站制作、鄢陵網頁制作以及鄢陵網絡營銷策劃等。多年來，我們專注于互聯(lián)網行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網行業(yè)的解決方案，鄢陵網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到鄢陵省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
今天，阿里云高級技術專家張磊將從 Kubernetes 1.14 這個承前啟后的版本聊起，一窺技術社區(qū)的演進方向。
Kubernetes 1.14 正式發(fā)布已經過去了一段時間，相信你已經從不同渠道看過了各種版本的解讀。
不過，相比于代碼 Release，馬上就要迎來5周歲生日的 Kubernetes 項目接下來如何演進，其實也是一個讓人著迷的話題。而作為一個日趨成熟的開源生態(tài)，Kubernetes 項目每三個月一次的正式發(fā)布，其實正是這個高速發(fā)展的技術社區(qū)不斷向前演進的過程中留下的扎實腳印。
Windows 生態(tài)成為 Kubernetes 項目的一等公民
Kubernetes 對 Windows 生態(tài)的支持，自從這個項目發(fā)布起就被提上了日程。不過，作為一個純粹的 Linux 技術棧支撐的基礎設施開源項目，Windows 節(jié)點以及 Windows 容器支持真正取得實質性進展，還是要從 Kubernetes 項目的插件和可擴展能力在1.6版本后逐漸成熟之后才慢慢步入了正軌。這也很容易理解，Windows 體系與目前主流容器技術棧有著本質性的差異，這就要求 Kubernetes 項目必須能夠提供更高層次的抽象和可擴展能力以支持兩種迥然不同的技術棧，并且同現有的Kubernetes 生態(tài)比如 CNI 和 CSI 完成對接。這部分工作的復雜度和工作量，也是 Windows Node 的生產可用從1.13延期到1.14的主要原因。
而在這次1.14的發(fā)布中，Kubernetes 的 Pod，Service，應用編排，CNI 網絡等絕大多數核心能力都已經在 Windows 節(jié)點上得到了支持。此外，包括自定義監(jiān)控指標、水平擴展、搶占和優(yōu)先級調度等很多進階功能也都在 Windows 上得以實現。
目前，尚不能被支持的功能基本上都是在 Windows 上暫時無法實現的語義比如 Host Network 以及其它 Linux 內核專屬的資源和權限定義方式等?？梢钥吹剑琄ubernetes 這次發(fā)布對 Windows 節(jié)點和 Windows 容器的支持，較之前相比有了巨大提升，完成度非常高，確實對得起 “GA”這個具備承諾意味的發(fā)布用語。
而國內外公共云提供商比如阿里云容器服務(ACK)也已經于近期已經推出了 Windows Container 的支持，提供了 Linux/Windows 應用混合部署的統(tǒng)一管理能力，再一次印證了這次發(fā)布的可用度。
不難看到，公共云提供商(比如本次Windows 支持GA背后的微軟云團隊)作為 CNCF社區(qū)的主要推動方之一，實際上一直在整個云原生技術生態(tài)中發(fā)揮著巨大的作用，逐步促成了將像 Windows 支持這樣的實際企業(yè)用戶訴求帶給了一個高速發(fā)展的、完全以 Linux 技術棧為核心的基礎設施項目。而在未來的發(fā)展中，諸如此類的來自于公共云提供商的輸入，將會繼續(xù)在 Kubernetes 項目發(fā)展的過程中扮演至關重要的角色，這也會成為更多的企業(yè)用戶能夠從云原生技術生態(tài)中獲益的一個重要途徑。這一點，將會繼續(xù)成為 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 鏡像是非常相似的，它可以規(guī)避“字符替換”對應用描述文件的入侵，也不需要用戶學習額外的 DSL 語法(比如 Lua)。
更為重要的是，上述PATCH 的思想，跟 Kubernetes 項目強調的聲明式 API 是完全匹配的，整個使用體驗跟 Kubernetes API 本身完全一致，沒有割裂感(大家可以思考一下為什么 PATCH 才是聲明式 API 的精髓)。
在1.14發(fā)布中，Kustomize 功能已經成為了 kubectl 的一個內置命令，這使得用戶使用 Kubernetes 的聲明式 API來直接在云端管理、修改和部署海量的應用成為了可能。并且，kubectl 本身的插件機制也在1.14中得到了大量完善，使得 kubectl 結合各種客戶端插件已經具備成為應用管理工具的潛在能力。而在這樣的演進路線下，Kubernetes 項目對應用以及應用管理的定義也開始清晰了起來，我們可以用如下一幅示意圖來簡單描述：
??
??
在這個 Kubernetes 原生的應用管理體系中，應用描述文件(YAML 文件)居于核心位置。一份應用描述文件，實際上是多個 Kubernetes API 對象的組合，共同定義了這個部署這個應用所需的資源編排和服務編排內容。一旦這樣一個描述文件提交給Kubernetes ，那么接下來它就會通過控制器模式來保證整個集群里的狀態(tài)與該描述文件的定義完全一致。
這些描述文件的來源，則來自于上層框架或者用戶的產出。更為重要的是，所有對應用的操作，都應該通過聲明式 API 對該文件進行 Create、Patch 和 Delete 操作來完成，進而觸發(fā) Kubernetes 的控制器模型執(zhí)行預定義的編排動作。
不難看到，在這個模型中，Helm 和 Kustomize 其實定義了兩種不同的應用描述文件的產出路徑和用戶體驗，也代表了兩種同 Kubernetes API 不同的耦合度和抽象程度：一個自成體系，一個則融入到了 Kubernetes的設計理念當中。在1.14發(fā)布之后，Kubernetes 社區(qū)當前正在探索的這種應用管理體系效果如何，我們不妨拭目以待。
大規(guī)模場景下的性能優(yōu)化工作逐漸提上日程
熟悉 Kubernetes 項目的很多參與者可能都知道，在過去一段時間，Kubernetes 社區(qū)對于大規(guī)模場景下的性能優(yōu)化工作的優(yōu)先級大多不會非常高。這里的原因也比較容易理解，在一個基礎設施開源項目發(fā)展的早期，擴大生態(tài)和完善功能相比于支持更大的集群來說往往要更重要一些。
但在 Kubernetes 的主干功能日趨穩(wěn)定之后，社區(qū)一定會開始更多地關注大規(guī)模場景下 Kubernetes 項目會暴露出來的各種各樣的問題，這其實依然容易理解：中小規(guī)模的用戶固然是整個項目取得生態(tài)成功的根本，但是通過 Kubernetes 這條路徑讓更多的沃爾瑪、星巴克、國內外的技術獨角獸們成為云原生技術的受益者，進而成為公共云上的規(guī)模性用戶，一定是 Kubernetes 社區(qū)要重點考慮的發(fā)展方向。
當然，作為一個天然處于“被集成”位置的基礎設施項目，Kubernetes 進行性能提升的主要方向，一定優(yōu)先關注于與上層使用者關系最為緊密的 API 層以及客戶端使用場景。當然，這也與 Kubernetes 項目的架構關系緊密：聲明式 API 的設計圍繞著以 etcd 為核心的配置管理機制，使得 Kubernetes 項目天生就是一個重 API 層而輕調度的分布式系統(tǒng)。這也意味著當需要管理的配置信息(即：API 對象)數量巨大時，這一層也是最有可能的暴露出性能問題的領域。
所以，在 Kubernetes v1.14中，社區(qū)首先從面向最終用戶的角度做出了很多優(yōu)化，比如： kubectl 對 API 對象的遍歷行為進行了大量的并行化工作。這種看似微小的修改在大規(guī)模場景下對 kubectl 使用者帶來的性能提升體驗，卻是非常顯著的。
當然，最重要的工作，還是發(fā)生在 APIServer 本身的性能優(yōu)化上。比如，Kubernetes 的 Aggregated API 允許開發(fā)人員編寫一個自定義服務，并把這個服務注冊到 k8s 的 API 里面像原生 API 一樣使用。但是在這個情況下，APIServer 會將用戶自定義 API Spec 與原生的 API Spec 歸并起來，這是一個非常消耗CPU 的性能痛點。而在v1.14中，社區(qū)專門對這個操作的效率進行了細致的優(yōu)化，終極將APIServer 歸并 Spec 的性能提升了十倍以上。
除此之外，Kubernetes 項目性能提升的另一個重要方向，就是對 etcd 到 APIServer 之間的連接路徑的優(yōu)化和提升上。作為 Kubernetes 項目的配置中心，也是外部數據依賴，etcd 每一次提交操作的數據量和間隔大小，每一個連接的請求和響應周期，都有可能對最終 Kubernetes 項目在大規(guī)模場景下的性能表現產生影響。阿里巴巴的技術團隊在 etcd 項目的中一直在持續(xù)進行性能調優(yōu)與提升工作并已陸續(xù)發(fā)布在了 etcd 的新版本當中。這些內容雖然不屬于 Kubernetes 1.14 發(fā)布的一部分，但同樣值得我們關注。
可擴展能力和項目穩(wěn)定性持續(xù)提升
除了上述幾個領域在本次發(fā)布后逐步成為核心領域之外，Kubernetes 項目在過往一直比較重視的幾個核心方向，比如，可擴展能力的提升，項目穩(wěn)定性等，依然是 Kubernetes 項目繼續(xù)演進的重要旋律。所以在 Kubernetes 1.14中，才會出現很多像“Pod Ready ++” 這樣將原本已經成熟的系統(tǒng)特性進一步重構成為可擴展接口的重要變更。在 Pod Ready ++ 正式發(fā)布后，Kubernetes 用戶只需要自己編寫一個外部控制器(Controller)就可以非常方便地自定義一個應用從創(chuàng)建到最終可用(Ready)的標準到底是什么，而不是被強迫遵守 Kubernetes 項目已有的定義方法。這種能力，同樣是基礎設施開源項目“民主化”的重要體現。
總結
Kubernetes 1.14的發(fā)布，在這個日趨成熟穩(wěn)定的項目開源基礎設施項目的發(fā)展過程中有著重要的承前啟后的作用。所以我們會看到，Kubernetes 社區(qū)正在幾個以往并不太受關注的領域里開始持續(xù)發(fā)力，甚至有可能會進一步改變整個云原生社區(qū)在某些領域的發(fā)展方向。這種在日趨穩(wěn)定的發(fā)展歷程中不時透露出來的技術革新，也正是這個社區(qū)能夠持續(xù)令人興奮的關鍵所在。
而放眼當前的云計算生態(tài)，國外越來越多的大規(guī)模企業(yè)級用戶比如 Snapchat、Twitter 等都已經開始了將自己的整套技術棧直接遷往以 Kubernetes 為基礎的公共云服務上，這正好印證了“云原生”這個關鍵詞的本質含義：在未來云的時代，軟件的開發(fā)、測試、發(fā)布、運維等完整的生命周期，都會基于云來進行。而所謂的“云原生”，其實正在通過一系列技術手段，為廣大開發(fā)者編制出了一幅能夠讓軟件天然的生長在云上、交付在云上，從而大程度地發(fā)揮出云的價值的技術藍圖。
更多關于云原生技術原理和實踐的內容，歡迎點擊文末“閱讀原文”關注阿里云和CNCF 官方聯(lián)合開發(fā)的免費公開課《CNCF x Alibaba 云原生技術公開課》：業(yè)內一線技術大咖為你剖析云原生技術核心原理與落地實踐，期待各位的學習與反饋。
參考資料：
??https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md??
【本文為專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】
??戳這里，看該作者更多好文??
分享名稱：從Kubernetes1.14發(fā)布，看技術社區(qū)演進方向
文章位置：http://m.5511xx.com/article/dpesdop.html
