Kubernetes 1.14.0 Release 已經(jīng)于3月25日正式發(fā)布。相信你也已經(jīng)注意到，相比于1.13 和 1.12 版本，這次發(fā)布包含的重要變更非常多，其對應(yīng)的?Release Note?的篇幅長度也創(chuàng)下了“新高”。

面對這樣一份“海量信息”的 Release Note，我們該如何從這份文檔里進(jìn)行高效的信息過濾和挖掘，幫助團(tuán)隊更精準(zhǔn)、快速的梳理出這次發(fā)布最主要的技術(shù)脈絡(luò)呢？

在本篇文章中，我們將?1.14 的Release Note 按照主題進(jìn)行了重新歸納和梳理，按照類別對重要變更進(jìn)行了技術(shù)剖析和討論。希望這種“分類解讀”的方式，能夠幫助大家更好的理解 1.14 這個發(fā)布的核心內(nèi)容。

Windows Node 正式生產(chǎn)可用

隨著1.14的發(fā)布，Kubernetes 對windows節(jié)點的生產(chǎn)級支持無疑是一個重要的里程碑。具體來說，1.14 版本針對 Windows 做了大量增強；
?

• Pod：Pod內(nèi)支持readiness和liveness探針；支持進(jìn)程隔離和volume共享的多容器Pod；Pod支持原生configmap和sercret；Pod支持emptyDir；支持對Pod進(jìn)行資源配額等；但是像優(yōu)雅刪除、Termination message、Privileged Containers、HugePages、Pod驅(qū)逐策略等部分特性還未在1.14版本提供；
• Service：支持服務(wù)環(huán)境變量提供DNS解析；支持NodePort、ClusterIP、LoadBalancer、Headless service；暫不支持Pod的hostnetwork模式；
• 常規(guī) Workload controller：RS、deployment、statefulset、daemonset、job、cronjob均支持windows容器；
• 除此之外，支持Pod和container維度的metrics、HPA、“kubectl exec”、調(diào)度搶占、resource quotas、CNI 網(wǎng)絡(luò)支持等多種特性讓windows workload更加云原生；由于windows的特殊兼容性，目前 host OS的版本必須和容器鏡像OS版本一致，1.14版本支持win server 2019；未來版本中會考慮使用Hyper-V隔離機(jī)制來解決版本兼容性問題。

而伴隨著? Windows 容器的生態(tài)正在慢慢壯大，能夠在生產(chǎn)級別支持 Windows?節(jié)點的容器服務(wù)開始見諸各大云廠商。阿里云容器服務(wù)（ACK）近期已經(jīng)推出了 Windows Container 的支持，提供了linux/windows應(yīng)用混合部署的統(tǒng)一管理能力。

參見：Support for Windows Nodes is Graduating to Stable (#116?)

本地持久化數(shù)據(jù)卷（Local PV） 正式可用

長期以來，能夠讓 Kubernetes 直接用宿主機(jī)的本地存儲設(shè)備（比如：本地 SSD 硬盤）來提供持久化數(shù)據(jù)卷（即：Local PV 功能），一直是社區(qū)里非常強烈的一個訴求。這個原因很容易理解：相對于遠(yuǎn)程存儲（網(wǎng)絡(luò)存儲），Local PV?在時延性、易用性、穩(wěn)定性和費用上具有獨特的優(yōu)勢，尤其是對于相關(guān)特性比較敏感的應(yīng)用，如數(shù)據(jù)庫應(yīng)用和搜索引擎應(yīng)用來說，有著重要的意義。

而在 1.14 中，Local PV 終于正式宣布 GA，為云上的持久化存儲選擇增加了一種重要的的可能。

不過，必須要明確的是， 選擇使用 Local PV，也意味著用戶必須自己承擔(dān)一些潛在的風(fēng)險，這包括：

• 目前社區(qū)的開源方案無法動態(tài)創(chuàng)建卷
• 調(diào)度器需要由額外的調(diào)度邏輯工作，以確保調(diào)度的節(jié)點可以分配出足夠的磁盤容量
• 容錯性差，如果pod正在運行的宿主機(jī)宕機(jī)或者磁盤發(fā)生異常，那么它的持久化卷里的信息可能丟失

第一個問題，可以通過比如阿里云的 local-volume-provisioner 實現(xiàn)本地 SSD Nvme實例自動創(chuàng)建數(shù)據(jù)卷來解決，但對于容錯性和健壯性的問題，就是比較棘手的了。

參見：Durable Local Storage Management is Now GA (#121)

Pod 優(yōu)先級與搶占機(jī)制穩(wěn)定可用

Kubernetes 里的任務(wù)優(yōu)先級（priority）和搶占機(jī)制（preemption）的目的十分明確：保證高優(yōu)先級的任務(wù)可以在需要的時候通過搶占低優(yōu)先級任務(wù)的方式得到運行。

這其中，優(yōu)先級定義了一個Pod在集群中的重要程度，這個重要程度體現(xiàn)且僅體現(xiàn)在兩個地方：（1）高優(yōu)先級的Pod在調(diào)度階段更容易被優(yōu)先調(diào)度（K8s采用隊列調(diào)度模型），注意這里并不保證高優(yōu)先級Pod永遠(yuǎn)被優(yōu)先調(diào)度，實際影響調(diào)度順序的因素有很多；（2）在集群整體負(fù)載較高時，如果出現(xiàn)高優(yōu)先級Pod無法被調(diào)度的情況（集群中沒有滿足條件的Node供Pod運行），K8s會啟動搶占機(jī)制，通過搶占已經(jīng)運行的低優(yōu)先級的Pod的方式，讓高優(yōu)先級的Pod可以運行起來。搶占機(jī)制便是在這里引入的。

搶占機(jī)制指當(dāng)調(diào)度器發(fā)現(xiàn)某個Pod（如Pod-A）無法在集群中找到合適的節(jié)點部署時（所有節(jié)點Predicates全部失敗），會試圖通過刪除一些優(yōu)先級低于Pod-A的Pod來“騰出空間”部署Pod-A，這樣Pod-A就可以被調(diào)度了。這樣一個“看似簡單”的需求在分布式環(huán)境中實施起來有很多細(xì)節(jié)，例如：如何決定刪除哪個節(jié)點的哪些Pod、如何保證為Pod-A騰出的空間不被其它Pod占用、如何保證Pod-A不被餓死（Starvation）、如何處理有親和性需求的Pod調(diào)度約束、是否需要支持跨節(jié)點Preemption以支持某些特定的約束（例如某Failure Domain的反親和約束）等等。這些內(nèi)容，可以參見：Pod Priority and Preemption in Kubernetes (#564)?

你一定要知道什么是 Pod Ready++

在 1.14 版本之前，Kubernetes 判斷一個Pod是否Ready，就是檢查這個Pod的容器是否全部正常運行。但是這里有個問題，那就是容器或者說里面的主進(jìn)程Ready，并不一定意味著這個應(yīng)用副本就一定是就緒的。為了確認(rèn)Pod確實可以正常可用，我們希望給它增加一些外部指標(biāo)（比如，該 Pod 需要的 Service，DNS，存儲等服務(wù)全部就緒），來反應(yīng)這個Pod是否“真正”Ready。

這個特性，就是1.14 里一個叫做“Pod Readiness Gates”、也叫做 Pod Ready ++ 的特性。它為pod的“Ready 狀態(tài)” 提供了一個非常強大的擴(kuò)展點。需要注意的是，用戶需要編寫一個外部控制器（Controller）來為這個Pod Readiness Gates 字段對應(yīng)的指標(biāo)設(shè)置值。

參見：Pod Ready++ (#580)?

Kubernetes 原生應(yīng)用管理能力

1.14之后，Kubernetes 項目本身開始具備了原生的應(yīng)用管理能力，這其中最重要的一個功能，就是 Kustomize。

Kustomize 允許用戶從一個基礎(chǔ) ?YAML 文件，通過 overlay 的方式生成最終部署應(yīng)用所需的 YAML 文件，而不是像 Helm 那樣通過字符串替換的方式來直接修改基礎(chǔ) YAML 文件（模板）。這樣，在一個用戶通過 overlay 生成新的 YAML 文件的同時，其他用戶可以完全不受影響的使用任何一個基礎(chǔ) YAML 或者某一層生成出來的 YAML 。這使得每一個用戶，都可以通過 fork/modify/rebase 這樣 Git 風(fēng)格的流程來管理海量的 YAML 文件。這種 PATCH 的思想跟 Docker 鏡像是非常類似的，它既規(guī)避了“字符串替換”對 YAML 文件的入侵，也不需要用戶學(xué)習(xí)蹩腳的 DSL 語法（比如 Lua）。

在1.14之后，Kustomize 已經(jīng)成為了 kubectl 的一個內(nèi)置命令。不難看到，Kubernetes 社區(qū)正在探索一種 Helm 之外的、更加 Kubernetes 原生的應(yīng)用管理方法。具體效果如何，我們不妨拭目以待。


參見：Added Kustomize as a subcommand in kubectl (#73033,?@Liujingfang1)

用戶友好度進(jìn)一步提升

隨著大家對Kubernetes越來越熟悉，對kubectl依賴也越來越強烈，需求也越來越多樣化。而在 1.14 中，kubectl 著重在以下幾個方面，提升用戶體驗，加強對日常運維能力的支持。

• 之前 kubectl cp 操作每次只能 copy 一個文件，沒辦法使用通配符拷貝一批文件，非常不方便。在1.14中，螞蟻金服的工程師提交了一個拷貝操作的通配符功能，方便對容器中的文件進(jìn)行操作。

  • 參見：#72641

• 以往，用戶通常無法方便的知道自己被管理員通過 RBAC 配置的權(quán)限到底有哪些。而從v1.14開始，用戶可以通過?kubectl auth can-i --list --namespace=ns1? 來查看自己在 ns1 這個namespace下可以訪問哪些資源 （比如Pod，Service等），并有哪些操作的權(quán)限（比如Get，List，Patch，Delete等）了。

  • 參見：#64820

• Kubernetes 用戶需要刪除的API 資源，往往分散在多個namespace中，刪除非常不方便。在v1.14新版本中，用戶終于可以借助于?kubectl delete xxx --all-namespaces? 來進(jìn)行統(tǒng)一的刪除操作了（這里 XXX 可以是Pod，Services，Deployment，自定義的CRD等等），并且還可以配合?-l?和?--field-selector?可以更精確地刪除滿足特定條件的資源。

  • 參見：#73716

穩(wěn)定性進(jìn)一步提升

和之前每個版本一樣，Kubernetes 的新版本發(fā)布對穩(wěn)定性和可靠性增強的關(guān)注一直是重中之重，下面我們列舉出一些值得注意的修復(fù)和升級。

• 在做Pod驅(qū)逐時，會優(yōu)先嘗試使用優(yōu)雅刪除模式，而不是暴力刪除etcd內(nèi)的Pod數(shù)據(jù)。這個修復(fù)能夠使被驅(qū)逐的 Pod更加優(yōu)雅的退出。

  • 參見：#72730

• Kubelet要重建Pod的容器時，如果舊容器是unknown狀態(tài)，現(xiàn)在Kubelet會首先嘗試Stop容器。這避免了一個 Pod的同一個容器申明會有多個實例同時運行的風(fēng)險。

  • 參見：#73802

• 在大規(guī)模集群中，節(jié)點因為個別Pod使用了大量磁盤 IO，可能會導(dǎo)致節(jié)點頻繁的在Ready/NotReady狀態(tài)之間變化。這種狀態(tài)會引起大規(guī)模的、不可預(yù)期的 Pod Eviction，導(dǎo)致線上故障。螞蟻金服的工程師針對 Docker 環(huán)境下的這個問題提交了修復(fù)，建議大家也排查一下其它運行時的集群里是否有同樣的問題。

  • 參見：#74389

• 當(dāng) Kubelet在壓力較大情況下，可能會發(fā)生 Kubelet 的Pod 生命周期事件消費頻次弱于事件產(chǎn)生頻次，導(dǎo)致負(fù)責(zé)這個事件的 Channel 被占滿，這種情況持續(xù)一段時間后會直接導(dǎo)致Kubelet 死鎖。阿里巴巴的工程師針對修這個問題提交了修復(fù)。

  • 參見：#72709

大規(guī)模場景下的性能提升與優(yōu)化

在 Kubernetes 的主干功能日趨穩(wěn)定之后，社區(qū)已經(jīng)開始更多的關(guān)注大規(guī)模場景下 Kubernetes 項目會暴露出來的各種各樣的問題。在v1.14中，Kubernetes 社區(qū)從面向最終用戶的角度做出了很多優(yōu)化，比如：

• kubectl 在實現(xiàn)中會順序遍歷 APIServer暴露出的全部資源的Group/Version/Kind，直到查找到需要處理的資源。這種遍歷方式導(dǎo)致了用戶在大規(guī)模集群下使用 kubectl 的性能體驗受到很大影響。在v1.14版本中，kubectl的順序遍歷行為終于改為了并行，極大地提升了kubectl的使用體驗（經(jīng)過測試，性能指標(biāo)提升了10倍以上）。

  • 參見：?#73345

• 在 1.14 中，APIServer 里的一個重要變更，是對單次 PATCH 請求內(nèi)容里的操作個數(shù)做出了限制，不能超過10000個，否則就不處理此請求。這樣做的目的，是防止 APIServer 因為處理海量的甚至是惡意PATCH 請求導(dǎo)致整個集群癱瘓。這也其實也是社區(qū)的 CVE-2019-1002100 主要的修復(fù)方法。

  • 參見：#74000

• Kubernetes 的 Aggregated API允許 k8s 的開發(fā)人員編寫一個自定義服務(wù)，并把這個服務(wù)注冊到k8s的 API 里面像原生 API 一樣使用。在這個情況下，APIServer?需要將用戶自定義 API Spec 與原生的 API Spec 歸并起來，這是一個非常消耗CPU 的性能痛點。而在v1.14中，社區(qū)大大優(yōu)化了這個操作的速率，極大地提升了APIServer?歸并 Spec 的性能（提升了不止十倍）。

  • 參見：#71223

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的寻找 K8s 1.14 Release 里的“蚌中之珠”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。