Kubernetes 1.19 發布 - OSCHINA - 中文開源技術交流社區

2020-12-26 開源中國

Kubernetes 1.19 現已發布,這是 2020 年的第二個版本,也是迄今為止最長的發布周期,總共持續 20 周。該版本包含了 33 項增強功能;  其中 12 項為穩定版功能、18 項為 beta 功能、還有 13 項為 alpha 版功能。主要更新亮點包括: 

將 Kubernetes 支持窗口增加到一年

長期支持(LTS)工作組在 2019 年初進行的一項調查顯示在當前的 9 個月支持期內,很大一部分 Kubernetes 用戶未能升級。這一點以及調查中的其他反應表明,如果將補丁支持期延長至 12-14 個月,則 30% 的用戶能夠將其部署保持在支持的版本上。無論用戶使用的是自建版還是商業發行版,情況都是如此。因此,延長支持期將導致超過 80% 的用戶使用受支持的版本,而不是現在的 50-60%。一年一度的支持期可為用戶提供所需的緩衝期,並且更符合熟悉的年度規劃周期。從 Kubernetes 1.19 版本開始,支持窗口將延長到一年。

儲存容量追蹤

傳統上,Kubernetes 調度器基於這樣的假設:集群中任何地方都可以使用額外的持久性存儲,並具容量無限。拓撲約束解決了第一點,但到目前為止,Pod 調度仍然沒有考慮剩餘的存儲容量可能不足以啟動一個新的 pod。存儲容量追蹤是一個新的 Alpha 特性,它通過為 CSI 驅動程序添加一個 API 來解決這個問題,以報告存儲容量,並在 Kubernetes 調度器中為 Pod 選擇節點時使用該信息。該功能可作為支持本地卷和其他容量限制較大的卷類型的動態預配置的基礎。

通用臨時存儲

Kubernetes 提供了卷插件,其生命周期與 Pod 綁定,可用作臨時空間(例如內置的 emptydir 卷類型),也可以將一些數據加載到 Pod 中(例如內置的configmap 和 secret 卷類型)。新的通用暫存卷 alpha 功能允許任何現有的支持動態供應的存儲驅動程序被用作 ephemeral 卷,並將該卷的生命周期綁定到 Pod。它可以用來提供不同於根磁碟的臨時存儲,例如持久內存或者該節點上的獨立本地磁碟。支持所有用於卷供應的 StorageClass 參數。支持PersistentVolumeClaims 支持的所有功能,如存儲容量跟蹤、快照和還原以及卷的大小調整。

CSI Volume 健康監測

CSI 健康狀況監控的 Alpha 版本隨 Kubernetes 1.19一起發布。該功能使 CSI 驅動程序能夠與 Kubernetes 共享來自底層存儲系統的異常卷狀況,以便將其作為事件報告在 PVC 或 Pod 上。此功能是 Kubernetes 進行程序檢測和解決單個卷健康問題的基礎。

Ingress 升級為 GA

就將 Ingress API 推向 GA 而言,API 本身在 Beta 版中已經存在了很長時間,以至於通過使用和採用(包括用戶和負載均衡器/Ingress 控制器提供商),它已經達到了事實上的 GA 狀態。在沒有全面替代的情況下放棄它不是一個可行的方法。它顯然是一個有用的 API,並且捕獲了一組不平凡的用例。在這一點上,似乎更謹慎的做法是將當前的 API 聲明為社區將支持的 V1 版本,同時開發 V2 Ingress API 或具有超集功能的完全不同的 API。

結構化日誌

在 v1.19 之前,Kubernetes 控制平面中的日誌記錄無法保證日誌消息和這些日誌中對 Kubernetes 對象的引用有任何統一的結構。這使得對日誌的解析、處理、存儲、查詢和分析變得困難,並迫使管理員和開發人員在大多數情況下依靠基於一些正則表達式的臨時解決方案。由於這些問題,任何基於這些日誌的分析解決方案都很難實現和維護。

新的 klog 方法

Kubernetes 1.19  版本為 klog 庫引入了新的方法,該方法提供了用于格式化日誌消息的更結構化的接口。每個現有的格式化日誌方法(InfofErrorf)都通過結構化方法(InfoSErrorS)進行匹配。新的日誌記錄方法將日誌消息作為第一個參數,將鍵值對列表作為可變參數的第二個參數。這種方法允許逐步採用結構化日誌記錄,而無需一次將所有 Kubernetes 轉換為新的API。

Kubelet 的客戶端 TLS 證書輪轉

kubelet 使用私鑰和證書對 kube-apiserver 進行認證。證書是在 kubelet 首次啟動時通過集群外機制提供給它的。自 Kubernetes v1.8 以來,集群已經包含了一個(beta)流程,用於獲取初始的證書/密鑰對,並在證書到期臨近時進行輪轉,在 Kubernetes v1.19 中,這個功能可以穩定下來了。

在 kubelet 啟動過程中,將對文件系統進行掃描,以查找由證書管理器管理的現有證書/密鑰對。如果有可用的證書/密鑰,則將加載它。如果沒有,則 kubelet 會檢查配置文件中的編碼證書值或 kubeconfig 中的文件引用。如果證書是一個 bootstrap 證書,則它將用於生成密鑰,創建證書籤名請求並向 API伺服器請求籤名的證書。

當到期臨近時,證書管理器會負責提供正確的證書,生成新的私鑰和請求新的證書。隨著 kubelet 請求證書的籤名是其啟動過程的一部分,並且不斷地對來自 kubelet 的證書籤名請求進行自動批准,以使集群變得易於管理。

此外還有其它更新內容,詳情查看發布說明: https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive/

相關焦點