Kubernetes 1.14重磅來襲，多項關鍵特性生產可用

走過了突飛猛進的2018年，Kubernetes在2019年終於迎來了第一個大動作：Kubernetes 1.14版本的正式釋出！Kubernetes 本次釋出的 1.14 版本，包含了 31 項增強，其中 10 項為 GA，12 項進入 beta 試用階段，7 個為全新的 alpha 功能。1.14 版本的主題是可擴充套件性，並且支援更多的業務場景，其中三個主要的功能具備生產可用，一個重要功能進入 beta 試用階段。總體而言，1.14 版本相比之前的版本更著重於將更多的功能推進到穩定狀態，尤其是部分關鍵功能對於使用者來說具有重大的里程碑意義。

Windows節點支援：生產可用

截至目前，1.14版本Windows節點支援已經穩定，支援將Windows節點作為工作節點，並向其排程Windows容器。Windows容器支援的引入，允許使用者通過Kubernetes的介面介面來體驗Windows容器，並見證Kubernetes對於Windows容器的價值。在同一叢集中同時編排Windows與Linux應用，對於擁有混合應用技術棧的企業，尤其是傳統企業，具有里程碑式的意義。

Windows容器關鍵特性包含：

• 支援Windows Server 2019作為工作節點
• 支援與Azure-CNI、OVN-Kubernetes 和 Flannel等外接容器網路外掛對接
• 改進了對Pod、服務型別、工作負載控制器和 metric/quota 的支援，使Windows容器基本匹配Linux容器所提供的能力

隨著1.14版本的釋出，Kubernetes已經能為提供相對完善的Windows容器基礎功能集，但如果考慮端到端商用落地Windows容器商用方案，使用者仍然不得不關注以下方面的成熟度限制：

1、作業系統版本限制：Windows容器對Windows系統以及docker版本都有更加嚴格的要求，例如Windows Server 2019/1809需要Docker EE-basic 18.09版本。

2、Hyper-V和Native容器的成熟度：整體相對弱於Linux容器，Native容器的安全隔離能有限，Hyper-V隔離方案仍然是alpha特性，需要持續完善；而對於依賴GPU、GUI的應用支援較弱，相關商用案例也較少。

3、Windows容器映象生態：

• 當前可用於Windows容器的base image有限，主要就是windowsservercore和nanoserver，針對實際場景的使用靈活度不高；
• Windows容器的基礎映象尺寸較大，而微軟的MCR服務(Microsoft Container Registry)尚未明確中國區CDN的上線時間，使用者往往需要花費較長的時間下載映象。

4、 網路方面：Windows容器目前支援5種不同的網路模式，雖然已有一些網路外掛宣稱可以滿足基本的使用要求，但效能和成熟度仍需驗證。

5、其他限制：

• 控制面master節點目前不能部署在Windows系統中，這意味著Kubernetes叢集必須包含使用Linux系統的主節點。
• 目前 Windows 容器並不支援 Pod 優雅刪除。並且在 Windows 容器環境中，對單檔案對映、特權容器、大頁記憶體支援、Node Problem Detection 等能力也都沒有提供支援。

在1.14版本穩定之後，Kubernetes社群將繼續完善對Windows容器支援，包括但不限於：

• 優化使用kubeadm在Windows環境下安裝節點
• 支援Calico CNI網路
• Hyper-V隔離模式下支援一個Pod內包含多個容器
• 支援Pod優雅刪除

kubectl外掛機制宣佈穩定，命令列外掛生態蓬勃發展

kubectl外掛機制GA

kubectl外掛機制允許開發者已獨立的二進位制的形式釋出自定義的kubectl子命令。這可以用於擴充套件kubectl具有更高階別的功能和附加的porcelain(例如新增set-ns命令)。
外掛必須具有kubectl-的命名字首，並儲存在使用者PATH中，為了GA，外掛機制已經被大大簡化了。目前有點類似Git的外掛系統。

整合kustomize

kustomize（https://GitHub.com/Kubernetes-sigs/kustomize）是K8s社群命令列興趣小組（SIG-CLI）的一個子專案，致力於為使用者提供一種可以重複使用配置的宣告式應用管理工具，讓使用者在配置工作中只需要管理和維護kubernetes的原生API物件，而不需要使用和管理複雜的模版。

在這次釋出的版本中，kustomize提供宣告式資源配置的建立修改等能力可以kubectl –k引數和kustomize子命令來執行。kustomize使用Kubernetes原生概念幫助使用者建立和複用資源配置。使用者可以利用 kubectl apply -k dir/將指定目錄的kustomization.yaml提交到叢集中。使用者還可以直接將自定義的資源配置傳送到標準輸入，而不是通過 kubectl kustomize dir/應用。
更多的kustomize子命令將會在kustomize程式碼倉庫中繼續開發完善，使用者可以通過更新獨立的kustomize二進位制檔案來體檢最新的kustomize特性。
 
據不完全統計，GitHub 上有超過 200 種 kubectl 相關的第三方命令列工具，隨著 kubectl 外掛機制穩定，相信這些工具很快會基於外掛機制標準化，更好地與 kubectl 整合，給使用者提供強大的擴充套件命令集。

隨本次 Kubernetes 1.14 版本釋出的，還有全新的 kubectl 文件及 Logo。社群重寫了 kubectl 文件，並重點聚焦使用宣告式的資源配置管理資源。目前 kubectl 文件已作為獨立的站點上線，地址為：https://kubectl.docs.kubernetes.io，新的 kubectl Logo 及吉祥物（kubee-cuddle）也被啟用。

持久化本地儲存卷：生產可用

歷經漫長的改進，持久化本地儲存卷特性終於在1.14版本中達到生產可用。

本地持久卷可以使用K8s節點上掛載的本地儲存裝置作為持久卷的來源。相對於遠端磁碟來說，持久化本地儲存擁有優越的效能，使用更少的系統開銷，更加適合分散式檔案系統以及資料庫等場景。相比於雲盤，本地SSD盤比遠端磁碟就具有更好的IO效能。相比於裸機，除了效能以外，本地儲存通常更加便宜，並且使用它是配置分散式檔案系統的必要條件。

雖然本地持久卷特性達到生產可用，但是易用性仍然沒有得到顯著的改進。使用者可以通過兩種相對手動的方式來使用持久化本地儲存特性：

• 使用者手動指定塊裝置的方式提供本地持久卷
• 使用 sig-storage-local-static-provisioner 外掛靜態維護本地卷的生命週期。

根據Pod及PVC狀態自動地維護各節點中本地持久卷的能力，仍然需要較長的時間在社群推進。

應用就緒狀態判斷的改進：Pod Readiness Gates (Pod Ready++)生產可用

對於Pod的狀態，Kubernetes為使用者提供了兩項判斷Pod執行情況的能力：Readiness（就緒狀態）和Liveness（存活狀態）。一個Pod被判斷為Ready（就緒），意味著所有初始化相關的工作已經完成，Pod可以接收處理外部訪問的請求。而Liveness則用於判斷已就緒的Pod是否持續處於正常工作中。

然而在實際使用中，特別是針對大型應用，情況往往比較複雜。由於K8s中大量採用的非同步機制、以及多種物件關係設計上的解耦，當應用例項數增加/刪除、或者應用版本發生變化觸發滾動升級時，系統並不能保證應用相關的Service、負載均衡器配置總是及時完成重新整理。在一些情況下，往往只是新的Pod完成自身初始化，系統尚未完成Endpoint、負載均衡器等外部可達的訪問資訊重新整理，老的Pod就立即被刪除，最終造成服務不可用。這對使用者來說是不可接受的。

Pod Ready++的引入正是為了修正Pod就緒狀態的判斷機制——使用者可以通過 ReadinessGates 自定義Pod就緒的條件（如，從外部訪問入口判斷新建的Pod開始處理外部請求），當使用者自定義的條件以及容器狀態都就緒時，kubelet才會標記Pod準備就緒。

在1.14版本中，Pod ready++特性達到了穩定，使用者可以在生產系統中直接使用該特性。需要注意的是：對於使用者自定義的就緒條件，一定需要有自定義的控制器配合更新Pod狀態，否則，Pod永遠不會變成就緒狀態。

Pod優先順序與搶佔式排程：生產可用

Pod優先順序與搶佔可以使K8s排程器在叢集資源耗盡的情況下優先排程更加重要的Pod，並且驅逐叢集中正在執行的相對不重要的Pod，為更重要的Pod騰出資源。Pod的重要性通過PriorityClassName定義，其中\u0026quot;system-node-critical\u0026quot; 和 “system-cluster-critical” 是兩個特殊的最高優先順序的關鍵詞。優先順序低的Pod在資源不足時，容易首先被驅逐，因而對於重要的daemonset或者重要的應用元件，使用者可以設定較高的優先順序防止被搶佔。

要使用優先順序與搶佔，管理員必須開啟Priority Admission Controller。使用者在為Pod設定PriorityClassName時，必須指向叢集中已建立的PriorityClass物件，否則Pod建立失敗。

PID限制：beta試用階段

程式ID (PID) 是Linux主機基本的資源，以往K8s沒有任何措施限制容器內的程式建立PID，如果PID資源耗盡，即使其他的資源充足，也可能導致主機不穩定。在引入PID限制特性後，K8s管理員可以通過kubelet啟動引數–pod-max-pids來設定每個Pod最大可啟動的程式數目，並通過–system-reserved和–kube-reserved兩項引數設定系統預留的PID數目。
PID限制特性帶來的主要好處有：

• 防止Pod因PID資源匱乏而不能正常執行
• 隔離Pod之間以及Pod與node之間的PID資源

Kubeadm

• 在高可用叢集中自動執行控制面之間的證書複製。
• *kubeadm join *命令使得使用者自定義叢集納管節點的工作流程變為可能。

總結：核心趨於穩定，面向使用者場景開枝散葉

結合最近幾次版本釋出來看，Kubernetes核心的發展越來越趨於穩定，1.14版本幾乎沒有引入大的新特性，而是把重點放在了讓已有特性的穩定上。正如許多人會說，Kubernetes正在變得無聊，事實上放眼整個雲原生生態，面向終端使用者的各種落地場景，仍有巨大的發展空間，許許多多圍繞Kubernetes的新專案仍然在如雨後春筍般地湧現，而K8s本身一些子專案的動態也開始進入人們的視野，不斷地被商業落地。相信2019年會是Kubernetes和雲原生技術面向使用者場景開枝散葉的一年。