科技

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

歷經漫長的改進,持久化本地儲存卷特性終於在 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 建立失敗。

程序 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 ?

Reference:科技日報

看更多!請加入我們的粉絲團

轉載請附文章網址

不可錯過的話題