原標題：Kubernetes 1.14增強30多個功能，10大更新點在這里

北京時間2019年3月26日，Kubernetes正式發(fā)布了今年的第一個大版本 1.14。本次發(fā)布包含了大量重要更新，以可擴展性、支持更多的工作負載、安全性為主題，共增強了30多個功能。

為了幫助百度智能云的容器用戶更快理解1.14新版本的變化，以及了解社區(qū)技術(shù)的演進趨勢，百度智能云容器團隊對新版本的特性進行了深入研究，梳理出10個最值得關(guān)注的要點。

1全面增強Windows支持

這次最令人驚喜的莫過于Kubernetes宣布Windows節(jié)點正式生產(chǎn)可用。1.14版本支持向集群添加Windows工作節(jié)點、調(diào)度Windows容器。相信隨著Windows應(yīng)用生態(tài)的加入，將再次提升Kubernetes的平臺能力。對混合應(yīng)用技術(shù)棧有需求的企業(yè)，可同時實現(xiàn)在Kubernetes上編排Windows與Linux應(yīng)用。

對Windows容器的支持得益于以下3個關(guān)鍵點：

1、Windows Server容器網(wǎng)絡(luò)的進步，提供了創(chuàng)建CNI（容器網(wǎng)絡(luò)接口）插件的基礎(chǔ)設(shè)施。

2、Windows Server2019發(fā)布的增強功能提供了最佳的容器支持。

3、Windows KEP提供了一組清晰且一致的目標、期望和可交付的成果。

本次對Windows容器支持的關(guān)鍵特性包括：

1、支持加入Windows Server 2019作為工作節(jié)點調(diào)度容器。

2、支持Azure-CNI、OVN-Kubernetes以及Flannel等第三方容器網(wǎng)絡(luò)插件。

3、改進了對Pod、服務(wù)類型、工作負載控制器和metric/quota的支持能力，使Windows容器盡可能匹配Linux容器現(xiàn)有能力。

不過仍舊需要關(guān)注以下限制：

• 節(jié)點OS版本限制：Windows Server 2019/1809。
• Docker版本限制：Docker EE-basic 18.09。
• 提供兩種容器實現(xiàn)方案：Hyper-V和Native容器，Native容器的安全隔離很有限，Hyper-V隔離方案仍然是alpha特性，需要持續(xù)完善。
• 依賴GPU、GUI的應(yīng)用支持未被生產(chǎn)環(huán)境驗證。整體能力相對弱于Linux容器。
• 目前支持5種不同的網(wǎng)絡(luò)模式，性能和成熟度仍需驗證。
• Windows容器的基礎(chǔ)鏡像體積較大，用戶在沒有中國區(qū)CDN場景下下載鏡像耗時久。
• 目前Master組件不能部署在Windows系統(tǒng)中，因此集群必須包含Linux系統(tǒng)的Master節(jié)點。
• 目前Windows容器并不支持Pod優(yōu)雅刪除。
• 對單文件映射、特權(quán)容器、大頁內(nèi)存支持等能力尚未提供支持。

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

本地持久化存儲卷（Local PV）可以使本地存儲設(shè)備成為Kubernetes的持久化存儲卷。雖然之前的Kubernets版本已經(jīng)提供了多種PV，但是本次存儲相對于其余使用遠程存儲的PV，在時延和穩(wěn)定性上具有明顯的優(yōu)勢。

對于期望使用Local PV的用戶，也有兩個問題需要提前關(guān)注：

1、易用性：Local PV需要提前創(chuàng)建對應(yīng)路徑，PV當前需要手動創(chuàng)建。kubernets-sig下的 Provisioner雖然目前支持動態(tài)創(chuàng)建PV, 但存儲卷依舊需要手動提供。

2、容錯性：Local PV依賴本地存儲，而本次存儲通常無法有效應(yīng)對磁盤故障，因此無法獲得網(wǎng)絡(luò)存儲所提供的可用性保障。

3支持進程數(shù)量限制

進程資源（Process Resources）是Linux的基本資源。如果不在Pod中對進程數(shù)量限制，可能會在容器內(nèi)任意fork進程過多，導(dǎo)致主機上的進程資源耗盡，引起主機上的守護進程（如: kubelet、docker、kube-proxy等）運行不穩(wěn)定。

容器是通過cgroup實現(xiàn)進程、CPU、Memory、 I/O 等資源的使用限制。Docker從1.11版本之后，已經(jīng)支持限制容器內(nèi)進程數(shù)量，啟動容器的時候，加入啟動參數(shù)-pids-limit，即可以控制容器內(nèi)最大的進程數(shù)量。

對進程數(shù)量的限制也一直是社區(qū)內(nèi)的強烈需求。本次更新對Kubernetes進程數(shù)量限制包括兩個方面：

• Pod to Pod pid隔離。kueblet增加啟動參數(shù)pod-max-pids，用于限制Pod內(nèi)最大的進程數(shù)量。該feature在v1.14 版本中作為beta版發(fā)布。
• Node to Pod pid 隔離。支持限制pid在Node Allocatable Level，可以為kube預(yù)留pid數(shù)量。該feature在v1.14 版本中作為Alpha版發(fā)布。

4設(shè)置Pod優(yōu)先級&搶占機制

在中型和大型集群中，為了提高資源利用率，Kubernetes允許工作負載的總量超過集群可以提供的資源總量，這種情況被稱為“過度承諾”。過度承諾在節(jié)點數(shù)量固定的集群中非常常見，在公有云中，客戶可以選擇過度運行其集群以節(jié)約成本。

Pod優(yōu)先級可以幫助管理員在過度運行集群時，為各種類型的工作負載定義其重要程度，從而在集群資源不足時選擇更加重要的工作負載優(yōu)先運行。當然，影響Kubernetes對工作負載重要程度的判斷不僅限于優(yōu)先級，也包括QoS和其它特定于集群的度量標準的組合。

在過度運行的前提下，當重要的工作負載無法獲得足夠資源運行時，Kubernetes將會通過搶占機制為Pod騰出足夠資源。搶占由調(diào)度程序執(zhí)行，通過釋放重要性低的Pod來實現(xiàn)。執(zhí)行搶占的組件必須具有為待處理的Pod找到正確節(jié)點的邏輯，它還必須具有檢查待搶占的“空間”是否允許調(diào)度待處理Pod的邏輯。這些要求組件具有謂詞和優(yōu)先級功能的知識。

讓調(diào)度程序執(zhí)行搶占有以下好處：

• 避免復(fù)制另一個組件中的所有調(diào)度邏輯。
• 降低Pod搶占和待處理Pod調(diào)度之間的競爭條件風(fēng)險。 如果這兩個都由調(diào)度程序執(zhí)行，則調(diào)度程序可以串行執(zhí)行它們（盡管當前不是原子的）。 如果由不同的組件執(zhí)行搶占，則調(diào)度程序可能在其Pod被搶占的節(jié)點上調(diào)度不同的Pod（而不是搶占者）。
• 如果有多個調(diào)度程序，競爭條件仍然存在。

5Pod readiness gates

Pod readiness gates為Kubernetes的Pod就緒狀態(tài)檢查提供了靈活的外部反饋擴展點。在Kubernetes中，通過就緒檢查來判斷Container、Pod、Endpoint的狀態(tài)是否就緒。在之前的版本中，這些對象的就緒條件如下：

• Container Readiness：Container ready = Container running并且readinessprobe檢測成功。
• Pod Readiness：Pod ready = All containers ready。
• Endpoint Readiness: Endpoint ready = Pod ready。

在傳統(tǒng)的做法中，只要容器主進程處于ready狀態(tài)，并且readinessProbe檢查成功，則container和Pod將會進入就緒狀態(tài)。但是此時Pod依賴的相關(guān)服務(wù)（如網(wǎng)絡(luò)策略、負載均衡器等）可能還未就緒。

通過1.14發(fā)布的readinessGates功能，可以通過接入Pod所依賴的外部指標來更好地確定Pod是否處于就緒狀態(tài)，readinessGates通過將用戶定義的額外的狀態(tài)反饋注入到PodStatus，來為判斷Pod的ready狀態(tài)添加可擴展性。

其主要實現(xiàn)方式為在pod readines上添加附加屬性readinessGates，使得Pod ready = All containers ready并且 readinessGates中的條件都檢測為True。在pod spec上新增readinessGates屬性，值為conditionType:string 列表，conditionType值指向pod status中的pod condition列表中的一項，依據(jù)該status來判定ready情況，若不存在則默認為false。

使用readinessGates的用戶需要注意：

• readinessGates只能在創(chuàng)建Pod時定義。
• readinessGates一旦創(chuàng)建不可更新。
• ConditionType必須符合自定義pod condition的命名約定。

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

1.14 版本的kubectl添加了子命令kustomize，同時為apply/delete/get子命令添加了-k參數(shù)，實現(xiàn)了Kustomize工具提供的應(yīng)用資源YAML管理功能。

Kustomize允許用戶使用一個或多個聲明了KUBERNETES API資源的YAML文件作為base，通過overlay的方式將patch應(yīng)用于base YAML生成目標YAML。這種方式可以方便地將一套YAML文件在不同環(huán)境下或不同用戶中進行復(fù)用，而不需要將YAML文件拷貝多份，再各自進行修改。該工具幫助用戶使用fork/modify/rebase工作流來復(fù)用KUBERNETES資源YAML，而不需要使用模板語言或腳本等侵入式方案進行資源管理。

Kustomize接受一個包含原始KUBERNETES API資源YAML文件和kustomization.yaml文件的目錄，根據(jù)kustomization.yaml文件內(nèi)容得到目標KUBERNETES API資源的YAML格式輸出。一個合法的kustomization.yaml中聲明了作為base的YAML文件，以及需要應(yīng)用在base YAML文件上的patch內(nèi)容，并支持namePrefix、commonLabels等字段以支持對name和label的批量修改。

7默認rbac發(fā)現(xiàn)機制加固

1.14版本之前，system:discovery和system:basic-user的ClusterRoleBindings都會包含system:unauthenticated主體。為了提升CRD的隱私性和集群安全狀況，默認RBAC不再授予未經(jīng)身份驗證的用戶對發(fā)現(xiàn)和權(quán)限檢查API的訪問權(quán)限。同時保留對當前API的非敏感子集的未經(jīng)身份驗證的訪問（例如 GET /healthz，GET /version）。

升級的集群會保留原先的行為，如果集群管理員希望在新集群中授予未經(jīng)身份驗證的用戶訪問權(quán)限，需要明確選擇暴露發(fā)現(xiàn)、權(quán)限檢查API。

• kubectl createclusterrolebinding anonymous-discovery —clusterrole=system:discoverygroup=system:unauthenticated
• kubectl create clusterrolebinding anonymous-access-review —clusterrole=system:basic-user —group=system:unauthenticated

8讓Kubectl用戶更友好

1.14版本對kubectl的使用進行了一些優(yōu)化，使得kubectl的用戶體驗更加友好。

kubectl插件機制GA

• kubectl插件機制允許使用獨立的二進制文件來發(fā)布自定義的 kubectl 子命令。這可以用于擴展kubectl具有更高級別的功能，如：添加set-ns命令來快速切換命名空間。
• 插件必須具有kubectl-的命名前綴，并保存在用戶PATH中，為了GA，插件機制已經(jīng)被大大簡化了，目前有點類似Git的插件系統(tǒng)。
• 修復(fù)kubectl plugin list存在的問題。

kubectl命令優(yōu)化

• kubectl logs命令可以組合使用-f 和-l命令，實現(xiàn)篩選+持續(xù)輸出日志。
• 增加kubectl auth can-i —list命令，允許用戶查看在特定命名空間下可以執(zhí)行哪些操作。
• 用戶可以使用kubectl delete {source} —all-namespaces來進行統(tǒng)一的資源刪除操作。

kubectl將廢棄的命令

• kubectl的—show-all參數(shù)，之前是deprecated狀態(tài)，這次更新中正式去掉。
• kubectl的convert命令，變成deprecated狀態(tài)，將在v1.17中被去掉。
• kubectl get中的—export參數(shù)，變成deprecated狀態(tài)，將在1.18中被去掉。

9優(yōu)化穩(wěn)定性

新版本提高了穩(wěn)定性。此次1.14許多修復(fù)優(yōu)化都是圍繞穩(wěn)定性展開，下面列舉一些比較重要的提升點：

1、在極端情況下Pod會在controller給新增節(jié)點打上污點之前被scheduler調(diào)度在新增節(jié)點上，為避免此類情況出現(xiàn)，Kubernetes新增TaintNodesByCondition準入插件，該插件用于給新加入集群的節(jié)點打上"not ready"的污點。

2、當創(chuàng)建大量引用configmap或者secret的Pod時，集群的調(diào)度速度會變慢直至node狀態(tài)變成notready而無法調(diào)度。Kubernetes1.14針對該問題進行了修復(fù)。

3、Kubelet會在重啟或者刪除容器前嘗試停止處于unknown狀態(tài)的容器。

4、鏡像如果只有一個tag但是關(guān)聯(lián)了多個倉庫，此類鏡像在回收的過程中不會再出現(xiàn)刪除失敗。

5、之前版本可能因為處理事件的channel滿導(dǎo)致死鎖，新版本通過丟棄來不及處理的事件來避免出現(xiàn)死鎖的情況。

6、修復(fù)kubectl describe無法獲取靜態(tài)Pod事件的問題。

7、驅(qū)逐Pod時默認采用優(yōu)雅刪除模式，該修復(fù)使得Pod的退出更加優(yōu)雅。

8、歷史版本某些情況下會出現(xiàn)daemonSet創(chuàng)建的Pod被調(diào)度在不存在的節(jié)點上，增加對此類Pod的刪除機制。

9、apiserver增加進程的優(yōu)雅退出機制，該機制確保apiserver在退出前處理已建立的連接。

10、歷史版本中某些情況下apiserver會在后端服務(wù)就緒之前去創(chuàng)建service的后端，出現(xiàn)服務(wù)不可訪問的異常情況，針對此類情況作了修復(fù)。

10大規(guī)模場景下性能優(yōu)化

除了穩(wěn)定性外，1.14對于大規(guī)模場景下的性能也進行優(yōu)化，具體包括：

• Scheduler組件的緩存快照算法得到優(yōu)化，提高了調(diào)度的吞吐量，目前能達到在5000節(jié)點的集群中平均每秒調(diào)度100個Pod（100是受limit限制，實際可能更高）。這是一個重要的里程碑。
• 提高了Scheduler組件的魯棒性，以保證未調(diào)度的Pod能夠在適當?shù)臅r候被重新調(diào)度。
• Kubectl遍歷APIServer的資源改為了并行模式，性能提升了10倍以上。
• Api-server的單個json patch操作個數(shù)不能多于10000個，否則就返回413，不處理該請求。

關(guān)于Kubernetes 1.14更新的更多信息，大家可以關(guān)注百度智能云微信公眾號，進行詳細查閱。

百度智能云也將在對新版本進行全面的驗證和測試之后，正式提供CCE對Kubernetes 1.14版本的支持，敬請期待。

本文作者：百度智能云CCE團隊

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。