Kubernetes 1.14增強(qiáng)30多個(gè)功能，10大更新點(diǎn)在這里

原標(biāo)題：Kubernetes 1.14增強(qiáng)30多個(gè)功能，10大更新點(diǎn)在這里

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

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

1全面增強(qiáng)Windows支持

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

對(duì)Windows容器的支持得益于以下3個(gè)關(guān)鍵點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Pod to Pod pid隔離。kueblet增加啟動(dòng)參數(shù)pod-max-pids，用于限制Pod內(nèi)最大的進(jìn)程數(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)先級(jí)&搶占機(jī)制

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

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

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

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

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

5Pod readiness gates

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

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

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

通過(guò)1.14發(fā)布的readinessGates功能，可以通過(guò)接入Pod所依賴的外部指標(biāo)來(lái)更好地確定Pod是否處于就緒狀態(tài)，readinessGates通過(guò)將用戶定義的額外的狀態(tài)反饋?zhàn)⑷氲絇odStatus，來(lái)為判斷Pod的ready狀態(tài)添加可擴(kuò)展性。

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

使用readinessGates的用戶需要注意：

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

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

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

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

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

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

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

升級(jí)的集群會(huì)保留原先的行為，如果集群管理員希望在新集群中授予未經(jīng)身份驗(yàn)證的用戶訪問(wèn)權(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版本對(duì)kubectl的使用進(jìn)行了一些優(yōu)化，使得kubectl的用戶體驗(yàn)更加友好。

kubectl插件機(jī)制GA

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

kubectl命令優(yōu)化

• kubectl logs命令可以組合使用-f 和-l命令，實(shí)現(xiàn)篩選+持續(xù)輸出日志。
• 增加kubectl auth can-i —list命令，允許用戶查看在特定命名空間下可以執(zhí)行哪些操作。
• 用戶可以使用kubectl delete {source} —all-namespaces來(lái)進(jìn)行統(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)定性展開，下面列舉一些比較重要的提升點(diǎn)：

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

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

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

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

5、之前版本可能因?yàn)樘幚硎录腸hannel滿導(dǎo)致死鎖，新版本通過(guò)丟棄來(lái)不及處理的事件來(lái)避免出現(xiàn)死鎖的情況。

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

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

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

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

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

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

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

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

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

百度智能云也將在對(duì)新版本進(jìn)行全面的驗(yàn)證和測(cè)試之后，正式提供CCE對(duì)Kubernetes 1.14版本的支持，敬請(qǐng)期待。

本文作者：百度智能云CCE團(tuán)隊(duì)

生成海報(bào)

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