Kubernetes 已足夠成熟?詳細解讀 1.15 新版本的多項關鍵特性

為促進社區發展,運維派尋求戰略合作、贊助、投資,請聯系微信:helloywp

作者 | 華為云原生團隊
2019 年 6 月 20 日,Kubernetes 重磅發布了 1.15 版本,不管你是 Kubernetes 用戶,還是 IT 從業者都不能錯過這個版本。

1.15 版本主要圍繞可擴展性展開,北向 API 接口方面 API Machinery SIG 致力于催熟 CRD 以提升 API 可擴展性,南向插件集成方面,Storage SIG 和 Node SIG 則分別對 CSI 和設備監控插件可擴展性進行了優化。另外 Kubeadm 對 HA 集群配置也達到 Beta 可用,并發優化了證書管理相關功能。

本文我們先從宏觀上了解一下近期版本的變化趨勢,然后再開始 1.15 版本的重點特性解讀。

Kubernetes 持續熱情高漲

在展開解讀 1.15 的關鍵新特性之前,讓我們先來回顧下社區過去幾個版本的特性發布情況。值得一提的是:無論從新特性數量,還是特性的成熟度分布來看,Kubernetes 依舊保持著相當的活力,社區開發者用實際行動回應了業界盛傳“Kubernetes 已經足夠成熟,項目正在變得無聊 (Boring)”的說法。

各版本新特性數量基本持平 ?

從新特性數量上看,Kubernetes 過去一個版本發布的特性數量并無明顯趨勢性變化。由于特性顆粒度的差異,每個版本發布的新特性數量存在小幅波動,屬于正常現象。

看特性成熟度分布,Alpha 特性比例依舊可觀 ?

對比分析過去幾個版本的特性成熟度,不難發現 Alpha 新特性的占比穩定在 20%~40% 之間。按照社區慣例,當一項全新的功能被添加時,會在特性說明中打上 Alpha 標記。持續穩定甚至小幅上漲的 Alpha 特性占比說明社區仍然在大量開發全新的特性,而不是滿足于既有功能的加固。

Kubernetes 重點特性解讀

經過分析 Kubernetes 近幾個版本的變化,我們發現特性主要集中在 Storage、Node、API-Machinery、Network、Scheduling 等 SIG,而這些 SIG 大都致力于可護展性增強,以便于下游用戶在享受穩定核心的同時,輕松擴展定制自己的插件。

從最新發布的 1.15 版本來看,以下幾個變化需要重點關注。

API 聚焦可擴展性增強 ?

Kubernetes API 的擴展能力主要由 CRD(Custom Resource Definition)以及 Admission Webhook 提供。1.15 版本在這兩方面都有重要的更新。

CRD,大步邁向 GA

CRD 的新開發主題一直都圍繞著數據一致性以及提供更加接近 Kubernetes 原生 API 的能力。用戶不應該感知到到底是以 CR(Custom Resource)還是以原生的資源對象形式與 Kube APIServer 進行交互。社區目前正邁著大步,計劃將在接下來的某個版本中將 CRD 以及 Admission Webhook GA(升級為穩定版本)。

朝著這個方向,社區重新思考了基于 OpenAPI 的 CRD 驗證模式,從 1.15 開始,根據結構模式(Structural Schema)的限制檢查每個字段。這基本保證了能夠像原生的 API 對象一樣提供完整的 CR 校驗能力。在 v1beta1 API 中,非結構模式(non-Structural Schema)仍然保持工作狀態。但是任何嚴格的 CRD 應用程序都應該在可預見的將來遷移到結構模式。

1) CRD 多版本之間通過 Webhook 轉換特性 [Beta]

從 1.15 版本開始,支持運行時不同版本之間的轉換,長期目標是讓用戶像原生 API 資源一樣使用 CRD 的多版本。這一特性是 CRD 在 GA 道路上一步重大的飛躍。

2) CRD OpenAPI 發布特性 [Beta]

CRD 的 OpenAPI 發布特性將會在 Kubernetes 1.15 中 Beta,當然只是針對結構模式的 CRD。次特性對于用戶自定義 API,提供了與 Kubernetes 原生 API 一樣的文檔說明。

3) CRD 未知字段裁剪(Prune)[Beta]

CRD 未知字段裁剪特性是針對發送到 Kube APIServer 的對象中未知的字段進行移除,并且不會持久化存儲。用戶可以通過在 CRD 對象設置 spec.preserveUnknownFields: false 使用此未知字段裁剪特性。此特性對于數據一致性及安全都有一定的幫助。

4) CRD 默認值設置 [Alpha]

Kubernetes 1.15 結構模式的 CRD 默認值設置特性作為 Alpha 特性可用。用戶可以通過 OpenAPI 校驗模式的 default 關鍵詞指定默認值。避免了用戶原來只能通過 Admission Webhook 方式設置 CRD 對象的默認值帶來的額外開發消耗。

Admission Webhook 重新調用(Reinvocation)與增強

1) Mutating 和 Validating Admission Webhook 已經成為擴展 API 的主流選擇。在 1.15 以前,所有的 webhook 只會按照字母表順序調用一次,這樣就會導致一個問題一個更早的 webhook 不能應對后面的 webhook 的更新,這可能會導致未知的問題,例如前面的 webhook 設置某個 pod 的啟動參數,而隨后的 webhook 將其更改或者移除了。

1.15 版本引入 Reinvocation 特性允許用戶通過 MutatingWebhook 配置 reinvocationPolicy: IfNeeded 指定 Mutating Webhook 重新調用。

2) Admission Webhook 引入了 objectSelector 來控制通過標簽選擇特定的對象進行準入控制。

3)允許 Admission Webhook Server 使用任意的端口(不限制只能是 443)。

Node SIG 提供監控插件框架用于異構硬件監控 ?

新版本很好的解決了異構硬件設備監控難題,現在不需要修改 Kubelet 代碼就可以實現各種指標(如 GPU、顯存利用率等)監控。

新版本通過新的監控插件框架將 Kubelet 與設備監控處理邏輯解耦,很好的解決了以往 Kubelet 代碼管理和 K8s 集群運維之間的痛點。

由圖可見本框架主要包含 Kubelet 和 Device Monitoring Agent 兩大部分:

1、Kubelet

Kubelet 增加了一個 GRPC 服務,監聽在 /var/lib/kubelet/pod-resources/kubelet.sock,提供 pod resources 的 list 查詢接口。

2、Device Monitoring Agent

a. Device Monitoring Agent 提供 metric 接口對外提供設備監控指標查詢功能。

b. Device Monitoring Agent 向 Kubelet 的上述 GRPC 服務發送 List 請求,取得所有 pod resources(包含節點上所有 pod 的所有 container 分配的 device 類型和 device id)。

c. Device Monitoring Agent 根據設備類型過濾獲取容器的設備 ID,通過設備驅動接口獲取容器使用的設備的監控指標,并把二者關聯到 container 、pod 上。

新的框架將會帶來諸多便利:

1、設備監控功能與 Kubelet 接口解耦

a. Kubelet 不需要提供設備的監控指標;

b. 設備的新增監控指標不需要升級 Kubelet,而是更新設備監控代理版本即可;

c. 新增設備不需要升級 Kubelet,而是增加部署設備監控代理的 DaemonSet 即可;

d. 未解耦前,Kubelet 會檢測所有支持的設備是否存在,即使節點并沒有安裝該設備。

2、設備供應商負責發布和維護設備監控代理,設備供應商在如何運行和監控它們方面擁有深厚的專業知識,可以提供權威的設備監控代理。

3、K8s 集群的管理員只需要安裝需要的設備監控代理即可。

Scheduling SIG 發布 Scheduler Framework 加強調度器擴展定制能力 ?

Scheduler Framework 終于在 1.15 迎來了 Alpha 版本。Scheduler Framework 最早在 2018 年初提出,主要是為了解決日益增加的定制化調度需求。Scheduler Framework 在原有的 Priority/Predicates 接口的基礎上增加了 reserve, pre-bind 等十幾個接口用于相應前處理及后處理。在 1.15 中,Scheduler Framework 實現 QueueSort, Prebind, Postbind, Reserve, Unreserve 和 Permit 接口,這些接口為后繼更多的調度策略提供了基礎,比如 gang-scheduling。

然而,出于設計上的延續性考慮,目前 Scheduler Framework 仍以 Pod 為單位進行調度,而計算類(離線)任務調度往往需要考慮工作負載中相關的 Pod 按組進行調度,例如 faire-share。現在的 Scheduler Framework 還不能有效的解決。所幸針對這一能力缺失,社區已經有相應的項目在 Kubernetes 上支持計算類(離線)任務,例如 Volcano (http://github.com/volcano-sh/volcano)。

Storage SIG 持續改善 CSI ?

在 Kubernetes v1.15 中,SIG Storage 繼續工作,以支持將 in-tree 插件遷移到 CSI(Container Storage Interface,容器存儲接口)。SIG Storage 致力于使 CSI 具有與 in-tree 功能相同的特性,包括調整大小、內聯卷等功能。SIG Storage 在 CSI 中引入了一些新的 Alpha 功能,這些功能在 Kubernetes 存儲子系統中還不存在,如卷克隆(volume cloning)等。

卷克隆允許用戶在提供新卷時將另一個 PVC 指定為“數據源(Data Source)”。如果底層存儲系統支持此功能并在其 CSI 驅動程序中實現“CLONE_VOLUME”功能,則新卷將成為源卷的克隆。

Kubeadm 的 HA 集群配置達到 Beta 可用 ?

作為社區內置安裝工具的 Kubeadm,何時支持部署 HA 集群一直是個熱門話題。在本次發布的 1.15 版本中,Kubeadm 對 HA 集群配置的支持終于達到 beta——用戶可以直接使用 init 和 join 兩個 Kubeadm 命令來部署 HA 集群。樂于折騰的用戶可以參考社區文檔在小范圍生產環境中使用。https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

Kubeadm 的證書管理功能在 1.15 中也得到了改進,用戶可以在證書失效前通過 kubeadm alpha certs renew 平滑地刷新它們。https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-certs-renew

Kubeadm 的 configuration(API) 在 1.15 版本中引入了 v1beta2 版本,主要是增加了一組證書加解密密鑰的配置字段 CertificateKey,便于用戶在使用 Kubeadm 部署 HA 控制面時,直接使用被加密保存在集群 Secret 中的證書。此外,用戶可以通過 kubeadm alpha certs certificate-key 命令來直接生成這對密鑰。

關于跟多 Kubeadm 當前相關的 Alpha 特性,可以查看相關官方文檔:https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha

隨著 Kubernetes 越來越多地被用在多云、混合云部署場景,集群生命周期管理的標準化一直是眾人期待的一大方向。自 v1.13 版本 GA 之后,Kubeadm 的改動主要聚焦在優化使用體驗上。而集群生命周期整體流程的打通,特別是實現跨平臺的集群管理,配合日漸活躍的 ComponentConfig 以及 Cluster API 兩個新項目,相信很快會有實質性的進展。

附圖:集群生命周期 SIG 相關項目成熟度

小結

經過 5 年的發展,Kubernetes 核心的基本功能已相對穩定,具備大規模生產可用水平。但是客戶需求往往是多種多樣的,社區從很早就意識到這個問題,因而提供了各種接口(CRD、CRI、CSI、CNI 等),希望在保持 Kubernetes 獨立的條件下,盡量滿足用戶差異化的需求,這從 1.15 發布的主要特性也可以看出來。

華為云原生團隊堅定的認為,Kubernetes 社區未來會繼續著重圍繞可擴展性、易用性以及穩定性規劃發展路標,豐富平臺面向各種應用場景的功能接口,以穩定、健壯、高可擴展的平臺推動云原生應用生態百花齊放。

網友評論comments

發表評論

電子郵件地址不會被公開。 必填項已用*標注

暫無評論

Copyright ? 2012-2019 YUNWEIPAI.COM - 運維派 - 粵ICP備14090526號-3
掃二維碼
掃二維碼
返回頂部
街机电玩捕鱼抢红包 精准免费彩票计划软件11远5 pt游戏平台 二人麻将下载不联网下载 动物狂欢压分必赢方法 黑龙江时时彩 顶尖娱乐官网 360时时彩 快速时时官网 骰子 梭哈玩法 澳贝娱乐登录app