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

作者 | 華為雲容器服務團隊

編輯 | 趙鈺瑩

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

1

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 容器商用方案，用戶仍然不得不關注以下方面的成熟度限制：

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

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

Windows 容器鏡像生態：

當前可用於 Windows 容器的 base image 有限，主要就是 windowsservercore 和 nanoserver，針對實際場景的使用靈活度不高；

Windows 容器的基礎鏡像尺寸較大，而微軟的 MCR 服務 (Microsoft Container Registry) 尚未明確中國區 CDN 的上線時間，用戶往往需要花費較長的時間下載鏡像。

網路方面：Windows 容器目前支持 5 種不同的網路模式，在異構的集群中，很難選擇同時兼容 Windows 和 Linux 的網路解決方案。儘管有一些可用的插件，但是不能保證與廠商已用的網路插件兼容。

其他限制：

控制面 master 節點目前不能部署在 Windows 系統中，這意味著 Kubernetes 集群必須包含使用 Linux 系統的主節點。

目前 Windows 容器並不支持 Pod 優雅刪除，單文件映射、特權容器、大頁內存支持、Node Problem Detection 等能力在 Windows 容器環境中都尚未支持。

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

優化使用 kubeadm 在 Windows 環境下安裝節點。

支持 Calico CNI 網路。

Hyper-V 隔離模式下支持一個 Pod 內包含多個容器。

支持 Pod 優雅刪除。

2

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）也被啟用。

新的 Kubectl Logo

3

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

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

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

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

用戶手動指定塊設備的方式提供本地持久卷

使用 sig-storage-local-static-provisioner 插件靜態維護本地卷的生命周期。

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

4

應用就緒狀態判斷的改進：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 永遠不會變成就緒狀態。

5

Pod 優先順序與搶佔式調度：生產可用

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

要使用優先順序與搶佔，管理員必須開啟 Priority Admission Controller。用戶在為 Pod 設置 PriorityClassName 時，必須指向集群中已創建的 PriorityClass 對象，否則 Pod 創建失敗。

6

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 資源。

7

Kubeadm

在高可用集群中自動執行控制面之間的證書複製。

kubeadm join 命令使得用戶自定義集群納管節點的工作流程變為可能。

8

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

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

友情推薦

量子位，領先的人工智慧媒體、科技媒體。行業進展、人物專訪、技術解析、學習教程，行業 技術全面報道，寫你看得懂的人工智慧。

點個在看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！