走過了突飛猛進(jìn)的2018年，Kubernetes在2019年終于迎來了第一個(gè)大動(dòng)作：Kubernetes 1.14版本的正式發(fā)布！Kubernetes 本次發(fā)布的 1.14 版本，包含了 31 項(xiàng)增強(qiáng)，其中 10 項(xiàng)為 GA，12 項(xiàng)進(jìn)入 beta 試用階段，7 個(gè)為全新的 alpha 功能。1.14 版本的主題是可擴(kuò)展性，并且支持更多的業(yè)務(wù)場(chǎng)景，其中三個(gè)主要的功能具備生產(chǎn)可用，一個(gè)重要功能進(jìn)入 beta 試用階段。總體而言，1.14 版本相比之前的版本更著重于將更多的功能推進(jìn)到穩(wěn)定狀態(tài)，尤其是部分關(guān)鍵功能對(duì)于用戶來說具有重大的里程碑意義。

Windows節(jié)點(diǎn)支持：生產(chǎn)可用

截至目前，1.14版本W(wǎng)indows節(jié)點(diǎn)支持已經(jīng)穩(wěn)定，支持將Windows節(jié)點(diǎn)作為工作節(jié)點(diǎn)，并向其調(diào)度Windows容器。Windows容器支持的引入，允許用戶通過Kubernetes的接口界面來體驗(yàn)Windows容器，并見證Kubernetes對(duì)于Windows容器的價(jià)值。在同一集群中同時(shí)編排Windows與Linux應(yīng)用，對(duì)于擁有混合應(yīng)用技術(shù)棧的企業(yè)，尤其是傳統(tǒng)企業(yè)，具有里程碑式的意義。

Windows容器關(guān)鍵特性包含：

• 支持Windows Server 2019作為工作節(jié)點(diǎn)
• 支持與Azure-CNI、OVN-Kubernetes 和 Flannel等外置容器網(wǎng)絡(luò)插件對(duì)接
• 改進(jìn)了對(duì)Pod、服務(wù)類型、工作負(fù)載控制器和 metric/quota 的支持，使Windows容器基本匹配Linux容器所提供的能力

隨著1.14版本的發(fā)布，Kubernetes已經(jīng)能為提供相對(duì)完善的Windows容器基礎(chǔ)功能集，但如果考慮端到端商用落地Windows容器商用方案，用戶仍然不得不關(guān)注以下方面的成熟度限制：

1、操作系統(tǒng)版本限制：Windows容器對(duì)Windows系統(tǒng)以及docker版本都有更加嚴(yán)格的要求，例如Windows Server 2019/1809需要Docker EE-basic 18.09版本。

2、Hyper-V和Native容器的成熟度：整體相對(duì)弱于Linux容器，Native容器的安全隔離能有限，Hyper-V隔離方案仍然是alpha特性，需要持續(xù)完善；而對(duì)于依賴GPU、GUI的應(yīng)用支持較弱，相關(guān)商用案例也較少。

3、Windows容器鏡像生態(tài)：

• 當(dāng)前可用于Windows容器的base image有限，主要就是windowsservercore和nanoserver，針對(duì)實(shí)際場(chǎng)景的使用靈活度不高；
• Windows容器的基礎(chǔ)鏡像尺寸較大，而微軟的MCR服務(wù)(Microsoft Container Registry)尚未明確中國(guó)區(qū)CDN的上線時(shí)間，用戶往往需要花費(fèi)較長(zhǎng)的時(shí)間下載鏡像。

4、 網(wǎng)絡(luò)方面：Windows容器目前支持5種不同的網(wǎng)絡(luò)模式，雖然已有一些網(wǎng)絡(luò)插件宣稱可以滿足基本的使用要求，但性能和成熟度仍需驗(yàn)證。

5、其他限制：

• 控制面master節(jié)點(diǎn)目前不能部署在Windows系統(tǒng)中，這意味著Kubernetes集群必須包含使用Linux系統(tǒng)的主節(jié)點(diǎn)。
• 目前 Windows 容器并不支持 Pod 優(yōu)雅刪除。并且在 Windows 容器環(huán)境中，對(duì)單文件映射、特權(quán)容器、大頁內(nèi)存支持、Node Problem Detection 等能力也都沒有提供支持。

在1.14版本穩(wěn)定之后，Kubernetes社區(qū)將繼續(xù)完善對(duì)Windows容器支持，包括但不限于：

• 優(yōu)化使用kubeadm在Windows環(huán)境下安裝節(jié)點(diǎn)
• 支持Calico CNI網(wǎng)絡(luò)
• Hyper-V隔離模式下支持一個(gè)Pod內(nèi)包含多個(gè)容器
• 支持Pod優(yōu)雅刪除

kubectl插件機(jī)制宣布穩(wěn)定，命令行插件生態(tài)蓬勃發(fā)展

kubectl插件機(jī)制GA

kubectl插件機(jī)制允許開發(fā)者已獨(dú)立的二進(jìn)制的形式發(fā)布自定義的kubectl子命令。這可以用于擴(kuò)展kubectl具有更高級(jí)別的功能和附加的porcelain(例如添加set-ns命令)。
插件必須具有kubectl-的命名前綴，并保存在用戶PATH中，為了GA，插件機(jī)制已經(jīng)被大大簡(jiǎn)化了。目前有點(diǎn)類似Git的插件系統(tǒng)。

集成kustomize

kustomize（https://GitHub.com/Kubernetes-sigs/kustomize）是K8s社區(qū)命令行興趣小組（SIG-CLI）的一個(gè)子項(xiàng)目，致力于為用戶提供一種可以重復(fù)使用配置的聲明式應(yīng)用管理工具，讓用戶在配置工作中只需要管理和維護(hù)kubernetes的原生API對(duì)象，而不需要使用和管理復(fù)雜的模版。

在這次發(fā)布的版本中，kustomize提供聲明式資源配置的創(chuàng)建修改等能力可以kubectl –k參數(shù)和kustomize子命令來執(zhí)行。kustomize使用Kubernetes原生概念幫助用戶創(chuàng)建和復(fù)用資源配置。用戶可以利用 kubectl apply -k dir/將指定目錄的kustomization.yaml提交到集群中。用戶還可以直接將自定義的資源配置發(fā)送到標(biāo)準(zhǔn)輸入，而不是通過 kubectl kustomize dir/應(yīng)用。
更多的kustomize子命令將會(huì)在kustomize代碼倉庫中繼續(xù)開發(fā)完善，用戶可以通過更新獨(dú)立的kustomize二進(jìn)制文件來體檢最新的kustomize特性。
?
據(jù)不完全統(tǒng)計(jì)，GitHub 上有超過 200 種 kubectl 相關(guān)的第三方命令行工具，隨著 kubectl 插件機(jī)制穩(wěn)定，相信這些工具很快會(huì)基于插件機(jī)制標(biāo)準(zhǔn)化，更好地與 kubectl 集成，給用戶提供強(qiáng)大的擴(kuò)展命令集。

隨本次 Kubernetes 1.14 版本發(fā)布的，還有全新的 kubectl 文檔及 Logo。社區(qū)重寫了 kubectl 文檔，并重點(diǎn)聚焦使用聲明式的資源配置管理資源。目前 kubectl 文檔已作為獨(dú)立的站點(diǎn)上線，地址為：https://kubectl.docs.kubernetes.io，新的 kubectl Logo 及吉祥物（kubee-cuddle）也被啟用。

持久化本地存儲(chǔ)卷：生產(chǎn)可用

歷經(jīng)漫長(zhǎng)的改進(jìn)，持久化本地存儲(chǔ)卷特性終于在1.14版本中達(dá)到生產(chǎn)可用。

本地持久卷可以使用K8s節(jié)點(diǎn)上掛載的本地存儲(chǔ)設(shè)備作為持久卷的來源。相對(duì)于遠(yuǎn)程磁盤來說，持久化本地存儲(chǔ)擁有優(yōu)越的性能，使用更少的系統(tǒng)開銷，更加適合分布式文件系統(tǒng)以及數(shù)據(jù)庫等場(chǎng)景。相比于云盤，本地SSD盤比遠(yuǎn)程磁盤就具有更好的IO性能。相比于裸機(jī)，除了性能以外，本地存儲(chǔ)通常更加便宜，并且使用它是配置分布式文件系統(tǒng)的必要條件。

雖然本地持久卷特性達(dá)到生產(chǎn)可用，但是易用性仍然沒有得到顯著的改進(jìn)。用戶可以通過兩種相對(duì)手動(dòng)的方式來使用持久化本地存儲(chǔ)特性：

• 用戶手動(dòng)指定塊設(shè)備的方式提供本地持久卷
• 使用 sig-storage-local-static-provisioner 插件靜態(tài)維護(hù)本地卷的生命周期。

根據(jù)Pod及PVC狀態(tài)自動(dòng)地維護(hù)各節(jié)點(diǎn)中本地持久卷的能力，仍然需要較長(zhǎng)的時(shí)間在社區(qū)推進(jìn)。

應(yīng)用就緒狀態(tài)判斷的改進(jìn)：Pod Readiness Gates (Pod Ready++)生產(chǎn)可用

對(duì)于Pod的狀態(tài)，Kubernetes為用戶提供了兩項(xiàng)判斷Pod運(yùn)行情況的能力：Readiness（就緒狀態(tài)）和Liveness（存活狀態(tài)）。一個(gè)Pod被判斷為Ready（就緒），意味著所有初始化相關(guān)的工作已經(jīng)完成，Pod可以接收處理外部訪問的請(qǐng)求。而Liveness則用于判斷已就緒的Pod是否持續(xù)處于正常工作中。

然而在實(shí)際使用中，特別是針對(duì)大型應(yīng)用，情況往往比較復(fù)雜。由于K8s中大量采用的異步機(jī)制、以及多種對(duì)象關(guān)系設(shè)計(jì)上的解耦，當(dāng)應(yīng)用實(shí)例數(shù)增加/刪除、或者應(yīng)用版本發(fā)生變化觸發(fā)滾動(dòng)升級(jí)時(shí)，系統(tǒng)并不能保證應(yīng)用相關(guān)的Service、負(fù)載均衡器配置總是及時(shí)完成刷新。在一些情況下，往往只是新的Pod完成自身初始化，系統(tǒng)尚未完成Endpoint、負(fù)載均衡器等外部可達(dá)的訪問信息刷新，老的Pod就立即被刪除，最終造成服務(wù)不可用。這對(duì)用戶來說是不可接受的。

Pod Ready++的引入正是為了修正Pod就緒狀態(tài)的判斷機(jī)制——用戶可以通過 ReadinessGates 自定義Pod就緒的條件（如，從外部訪問入口判斷新建的Pod開始處理外部請(qǐng)求），當(dāng)用戶自定義的條件以及容器狀態(tài)都就緒時(shí)，kubelet才會(huì)標(biāo)記Pod準(zhǔn)備就緒。

在1.14版本中，Pod ready++特性達(dá)到了穩(wěn)定，用戶可以在生產(chǎn)系統(tǒng)中直接使用該特性。需要注意的是：對(duì)于用戶自定義的就緒條件，一定需要有自定義的控制器配合更新Pod狀態(tài)，否則，Pod永遠(yuǎn)不會(huì)變成就緒狀態(tài)。

Pod優(yōu)先級(jí)與搶占式調(diào)度：生產(chǎn)可用

Pod優(yōu)先級(jí)與搶占可以使K8s調(diào)度器在集群資源耗盡的情況下優(yōu)先調(diào)度更加重要的Pod，并且驅(qū)逐集群中正在運(yùn)行的相對(duì)不重要的Pod，為更重要的Pod騰出資源。Pod的重要性通過PriorityClassName定義，其中\(zhòng)u0026quot;system-node-critical\u0026quot; 和 “system-cluster-critical” 是兩個(gè)特殊的最高優(yōu)先級(jí)的關(guān)鍵詞。優(yōu)先級(jí)低的Pod在資源不足時(shí)，容易首先被驅(qū)逐，因而對(duì)于重要的daemonset或者重要的應(yīng)用組件，用戶可以設(shè)置較高的優(yōu)先級(jí)防止被搶占。

要使用優(yōu)先級(jí)與搶占，管理員必須開啟Priority Admission Controller。用戶在為Pod設(shè)置PriorityClassName時(shí)，必須指向集群中已創(chuàng)建的PriorityClass對(duì)象，否則Pod創(chuàng)建失敗。

PID限制：beta試用階段

進(jìn)程ID (PID) 是Linux主機(jī)基本的資源，以往K8s沒有任何措施限制容器內(nèi)的進(jìn)程創(chuàng)建PID，如果PID資源耗盡，即使其他的資源充足，也可能導(dǎo)致主機(jī)不穩(wěn)定。在引入PID限制特性后，K8s管理員可以通過kubelet啟動(dòng)參數(shù)–pod-max-pids來設(shè)置每個(gè)Pod最大可啟動(dòng)的進(jìn)程數(shù)目，并通過–system-reserved和–kube-reserved兩項(xiàng)參數(shù)設(shè)置系統(tǒng)預(yù)留的PID數(shù)目。
PID限制特性帶來的主要好處有：

• 防止Pod因PID資源匱乏而不能正常運(yùn)行
• 隔離Pod之間以及Pod與node之間的PID資源

Kubeadm

• 在高可用集群中自動(dòng)執(zhí)行控制面之間的證書復(fù)制。
• *kubeadm join *命令使得用戶自定義集群納管節(jié)點(diǎn)的工作流程變?yōu)榭赡堋?/li>

總結(jié)：核心趨于穩(wěn)定，面向用戶場(chǎng)景開枝散葉

結(jié)合最近幾次版本發(fā)布來看，Kubernetes核心的發(fā)展越來越趨于穩(wěn)定，1.14版本幾乎沒有引入大的新特性，而是把重點(diǎn)放在了讓已有特性的穩(wěn)定上。正如許多人會(huì)說，Kubernetes正在變得無聊，事實(shí)上放眼整個(gè)云原生生態(tài)，面向最終用戶的各種落地場(chǎng)景，仍有巨大的發(fā)展空間，許許多多圍繞Kubernetes的新項(xiàng)目仍然在如雨后春筍般地涌現(xiàn)，而K8s本身一些子項(xiàng)目的動(dòng)態(tài)也開始進(jìn)入人們的視野，不斷地被商業(yè)落地。相信2019年會(huì)是Kubernetes和云原生技術(shù)面向用戶場(chǎng)景開枝散葉的一年。

總結(jié)

以上是生活随笔為你收集整理的Kubernetes 1.14重磅来袭，多项关键特性生产可用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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