Kube.NETes v1.28 正式發布了，這是 2023 年的第二個版本。該版本包含 45 項增強功能。其中，19 項進入 Alpha 階段，14 項升級到 Beta 階段，12 項升級到穩定版。
一、版本主題和徽標
Kubernetes v1.28 的主題是 Planternetes。
下面是 Kubernetes 1.28 的徽標。
每一次 Kubernetes 的版本發布，都代表著我們社區中成千上萬人的共同努力與成果。參與此次發布的人員背景各異，有的是行業資深人士，有的是家長，還有的是學生或是開源領域的新手。我們匯集了各自的經驗與專長，共同打造了這一具有全球影響力的產品。
這像一個花園，我們的發布像其生長中的植物一樣，經歷了各種變化、挑戰和機遇。此次的主題就是為了紀念我們付出的精心照料、決心和努力，證明我們和諧共生，共同成長。
二、新功能（主要主題）
1.支持的控制平面和節點版本間的差異進行了調整
這次更新允許測試并擴展核心節點和控制平面組件間的支持版本差異，從之前的 n-2 版本擴展至 n-3 版本。這意味著，受支持的最早的小版本中的節點組件（如 kubelet 和 kube-proxy）可以與最新受支持的小版本的控制平面組件（如 kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）協同工作。
這對終端用戶很有價值，因為控制平面升級比節點升級要快一些，而節點升級幾乎總是要比運行中的工作負載升級時間更長。
Kubernetes 已經提供了年度支持期，用戶可以隨時升級到最新的補丁版本以修復安全問題，每年還可以連續進行 3 次小版本的升級，以便與最新支持的小版本保持同步。
但當前的問題是，節點與控制平面之間經過測試并支持的版本偏差限制在兩個版本，這意味著三個版本的升級將需要兩次更新節點，以保證保持在受支持的版本偏差范圍內。
2.GA：從非正常節點關閉中恢復
如果節點意外關閉或最終處于不可恢復的狀態（可能是由于硬件故障或操作系統反應遲鈍），Kubernetes 允許你進行事后清理，并允許有狀態的工作負載在不同的節點上重新啟動。對于 Kubernetes v1.28，這是一項穩定的功能。
這意味著，當原始節點被關閉或遭遇如硬件故障或系統損壞的非可恢復狀態時，狀態性工作負載可以成功地切換到另一個節點。
Kubernetes v1.20 之前的版本缺乏對 linux 上節點關閉的處理，而 kubelet 集成了 systemd 并實現了優雅的節點關閉（beta 版，默認已啟用）。不過，即使是有意關閉，也可能無法得到很好的處理，這可能是因為：
- 節點運行 windows
- 節點運行 Linux，但使用不同的啟動程序（非 systemd）
- 關機沒有觸發系統抑制鎖機制
- 節點級配置錯誤（如未為 shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 設置適當的值）。
當節點關閉或發生故障，而 kubelet 又未檢測到該節點關閉時，作為 StatefulSet 一部分的 Pod 將停留在關閉節點上的終止狀態。如果停止的節點重新啟動，該節點上的 kubelet 可以清理（DELETE）Kubernetes API 仍然認為與該節點綁定的 Pod。
但是，如果節點一直處于停止狀態，或者 kubelet 在重啟后無法啟動，那么 Kubernetes 可能無法創建替代 Pod。當關閉節點上的 kubelet 無法刪除舊的 Pod 時，相關的 StatefulSet 就無法創建新的 Pod（名稱相同）。
存儲方面也有問題。如果有 Pod 使用的卷，現有的 VolumeAttachments 不會與原始節點（現已關閉）分離，因此這些 Pod 使用的 PersistentVolumes 無法連接到其他健康的節點。因此，在受影響的 StatefulSet 上運行的應用程序可能無法正常運行。
如果原來關閉的節點恢復運行，那么它們的 Pod 將被其 kubelet 刪除，新的 Pod 可以在不同的運行節點上創建。如果原始節點沒有啟動（這在不可變的基礎設施設計中很常見），這些 Pod 將永遠停留在關閉節點上的 “終止” 狀態。
有關如何在非順利節點關閉后觸發清理的詳細信息，請閱讀：
https://kubernetes.io/docs/concepts/architecture/nodes/#non-graceful-node-shutdown
3.改進 CustomResourceDefinition 驗證規則
通用表達式語言（CEL）可用于驗證自定義資源。其主要目標是允許大多數驗證用例，而這些用例曾經可能需要你作為自定義資源定義（CRD）的作者來設計和實現 webhook。取而代之的是，作為一個 beta 功能，你可以將驗證表達式直接添加到 CRD 的模式中。
直接支持復雜驗證對于 CRD 來說是必要的。盡管接納 webhooks 支持 CRD 驗證，但它們使 CRD 的開發和操作變得相對復雜。
在 1.28 中，添加了兩個可選字段 reason 和 fieldPath，用戶可以指定失敗的原因和字段路徑。
更多信息，請閱讀：
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
4.ValidatingAdmissionPolicies 升級到測試版
用于入場控制的通用表達式語言是對 Kubernetes API 服務器請求的可定制、進程內驗證，可替代驗證入場 webhooks。
為入場控制的通用表達式語言提供了一種定制化的、內置的請求驗證方法，這是對驗證入場 webhooks 的一個替代方案。
該功能建立在 1.25 版升級到測試版的 CRD 驗證規則功能的基礎上，但側重于驗證入場控制的策略執行功能。
這將降低執行可定制策略的基礎架構障礙，并提供有助于社區建立和遵守 Kubernetes 及其擴展的最佳實踐的原語。
要使用 ValidatingAdmissionPolicies，你需要啟用集群控制平面中的 admissionregistration.k8s.io/v1beta1 API 組和ValidatingAdmissionPolicy 功能門。
5.接納 webhook 的匹配條件
Kubernetes v1.27 版允許你為入場 webhooks 指定匹配條件，這讓你可以縮小 Kubernetes 在入場時進行遠程 HTTP 調用的范圍。ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 的 matchCondition 字段是一個 CEL 表達式，其值必須為 “true”，接納請求才會發送到 Webhook。
在 Kubernetes v1.28 中，該字段被移至 beta 版，并且默認啟用。
要了解更多信息，請參閱：
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchconditions
6.Beta 版支持在 Linux 上啟用交換空間
這將以可控、可預測的方式為節點添加交換支持，以便 Kubernetes 用戶可以執行測試并提供數據，繼續在交換基礎上構建集群功能。
交換有兩種不同類型的用戶，他們可能會重疊：
- 節點管理員，他們可能希望交換能用于節點級性能調整和穩定性 / 減少嘈雜鄰居問題。
- 應用開發人員，他們編寫的應用程序將從使用交換內存中受益。
7.混合版本代理（alpha）
當一個集群擁有多個混合版本的 API 服務器時（例如在升級/降級期間，或運行時配置發生變化和部署發生時），并非每個 apiserver 都能為每個版本的每個資源提供服務。
對于 Kubernetes v1.28，可以在 API 服務器的聚合層中啟用混合版本代理。混合版本代理會查找本地 API 服務器無法識別、但控制平面內的另一個 API 服務器能夠支持的請求。找到合適的對等程序后，聚合層會將請求代理到兼容的 API 服務器；從客戶端的角度來看，這是透明的。
在集群上執行升級或降級時，控制平面內的 API 服務器可能會在一段時間內處于不同的版本；當這種情況發生時，API 服務器的不同子集能夠為不同的內置資源集提供服務（不同的組、版本和資源都是可能的）。這種新的 alpha 功能可以幫助你向客戶端隱藏這種偏差。
8.控制平面組件的源代碼重組
Kubernetes 的貢獻者們已經開始重組 kube-apiserver 的代碼，以建立一個新的暫存倉庫，該倉庫消耗 k/apiserver，但擁有更大的、精心挑選的 kube-apiserver 功能子集，從而使其可以重用。
這是一個循序漸進的重組過程；最終會有一個新的 Git 倉庫，其通用功能將從 Kubernetes 的 API 服務器中抽象出來。
9.支持將 CDI 注入容器（alpha）
CDI 提供了將復雜設備注入容器的標準化方式（即邏輯上需要注入不止一個 /dev 節點才能工作的設備）。這一新特性使插件開發人員能夠利用 1.27 版中添加到 CRI 的 CDIDevices 字段，將 CDI 設備直接傳遞給啟用了 CDI 的運行時（如 contAInerd 和 crio-o 的最新版本）。
10.Sidecar 容器的 API 感知（alpha）
Kubernetes 1.28 為 init 容器引入了一個 alpha restartPolicy 字段，并用它來指示 init 容器何時也是 Sidecar 容器。它將按照定義的順序與其他 init 容器一起啟動，并設定 restartPolicy 為 Always。kubelet 會在啟動 Pod 的主容器前僅等待 Sidecar init 容器啟動。
啟動完成的條件是啟動探針成功（或未定義啟動探針）且 postStart 處理程序已完成。該條件用 ContainerStatus 類型的字段 Started 表示。
對于 init 容器，可以省略重啟策略字段，或將其設置為 Always。省略該字段意味著你想要一個真正的 init 容器，在應用啟動前完成。
Sidecar 容器不會阻止 Pod 的完成：如果所有常規容器都已完成，該 Pod 中的 Sidecar 容器也將終止。
對于 Sidecar 容器，重啟行為比 init 容器更復雜。在重啟策略設置為 Never 的 Pod 中，在 Pod 啟動過程中失敗的 Sidecar 容器不會被重啟，整個 Pod 將被視為失敗。如果 Pod 的 restartPolicy 是 Always 或 OnFailure，則會重試啟動失敗的 Sidecar 容器。
一旦 Sidecar 容器啟動（進程正在運行、postStart 成功且任何配置的啟動探針都已通過），然后出現故障，即使 Pod 的整體重啟策略為 Never 或 OnFailure，Sidecar 容器也會重新啟動。此外，即使在 Pod 終止期間，也會重啟（在失敗或正常退出時）Sidecar 容器。
要了解更多信息，請閱讀：
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers
11.自動、追溯性地為默認的 StorageClass 賦值現已穩定
如果沒有提供值，Kubernetes 會自動為 PersistentVolumeClaim （PVC） 設置一個 StorageClassName。對于那些沒有定義 storageClassName 的現有 PVC，控制平面也會自動設置一個 StorageClass。Kubernetes 以前的版本也有這種行為；Kubernetes v1.28 則是自動的，并且始終處于激活狀態；該功能已升級到穩定版（一般可用性）。
要了解更多信息，請閱讀：
https://kubernetes.io/docs/concepts/storage/storage-classes/
12.Job 的 Pod 替換策略（alpha）
Kubernetes 1.28 為作業 API 添加了一個新字段，允許你指定是希望控制平面在之前的 Pod 開始終止時立即創建新 Pod（現有行為），還是僅在現有 Pod 完全終止時才創建新 Pod（新的可選行為）。
許多常見的機器學習框架（如 Tensorflow 和 JAX）都要求每個索引有唯一的 Pod。在舊的行為中，如果屬于索引 Job 的 Pod 進入終止狀態（由于搶占、驅逐或其他外部因素），會創建一個替換 Pod，但由于與尚未關閉的舊 Pod 沖突，替換 Pod 會立即無法啟動。
在前一個 Pod 完全終止之前出現一個替代 Pod，也會給資源稀缺或預算緊張的集群帶來問題。這些資源可能很難獲得，因此只有在現有 Pod 終止后，Pod 才能找到節點。如果啟用了群集自動分級器，提前創建替代 Pod 可能會產生不希望的擴展。
要了解更多信息，請閱讀：
https://kubernetes.io/docs/concepts/workloads/controllers/job/#delayed-creation-of-replacement-pods
13.每個索引的 Job 重試后退限制（alpha）
此功能擴展了 Job API，支持索引任務，在索引 Job 中，重試限制是按索引計算的，Job 可以在部分索引失敗的情況下繼續執行。
目前，索引 Job 的索引共享一個延遲限制。當作業達到這個共享的延遲限制時，作業控制器會將整個作業標記為失敗，并清理資源，包括尚未運行完成的索引。
因此，現有的實現并沒有涵蓋這種情況，即工作負載真正地令人尷尬地并行：每個索引都完全獨立于其他索引。
例如，如果索引 Job 被用作一套長期運行的集成測試的基礎，那么每次測試運行只能發現一個測試失敗。
更多信息，請閱讀：
https://kubernetes.io/docs/concepts/workloads/controllers/job/#handling-pod-and-container-failures
14.沒有 cAdvisor 的 CRI 容器和 Pod 統計信息
這包括兩項相關工作（修改 kubelet 的 /metrics/cadvisor 端點和改進替換摘要 API）。
消費者主要使用兩個 API 來收集有關正在運行的容器和 Pod 的統計數據：summary API 和 /metrics/cadvisor。Kubelet 負責實現 summary API，cAdvisor 負責實現 /metrics/cadvisor。
這增強了 CRI 實現，使其能夠滿足 Kubernetes 的所有統計需求。從高層次來看，這有兩個部分：
- 它增強了 CRI API，為其提供了足夠的指標，以便直接從 CRI 補充摘要 API 中的 Pod 和容器字段。
- 增強 CRI 實現，以廣播所需的指標，從而滿足 /metrics/cadvisor 端點中 Pod 和容器字段的要求。
三、Kubernetes v1.28 中的功能升級和棄用
1.升級到穩定版
該版本共包含 12 項升級到穩定版的增強功能：
- kubectl 事件
- 追溯默認 StorageClass 分配
- 非正常關閉節點
- 支持第三方設備監控插件
- 獲取自用戶屬性的 Auth API
- 代理終止端點
- 擴展 DNS 配置
- 清理 IPTables 鏈所有權
- 最小化 iptables-restore 輸入大小
- 將 kubelet pod 資源端點升級為 GA
- 擴展 podresources API 以報告可分配資源
- 將 EndpointSlice Reconciler 移入暫存階段
2.停用和刪除
1）刪除：
- 移除針對 GCE PD 的 CSI 遷移
2）停用：
- Ceph RBD 內部插件
- Ceph FS 內部插件
下載鏈接：
https://Github.com/kubernetes/kubernetes/releases/tag/v1.28.0
作者丨Kubernetes v1.28 Release Team
編譯丨分布式實驗室（ID：DistributedLab）
來源丨https://kubernetes.io/blog/2023/08/15/kubernetes-v1-28-release/
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：editor@dbaplus.cn
