原本計(jì)劃于4月19日發(fā)布的Kubernetes 1.24，一直延遲到5月3日才發(fā)布。此版本帶來(lái)了46項(xiàng)增強(qiáng)，其中13項(xiàng)升級(jí)到穩(wěn)定版，14項(xiàng)是不斷改進(jìn)的現(xiàn)有功能，13項(xiàng)是全新的，6項(xiàng)已棄用的功能。

主要更新如下：

完全移除Dockershim

在 v1.20 中標(biāo)記棄用后，dockershim 組件已從 kubelet 中刪除。從 v1.24 開(kāi)始，您將需要使用其他受支持的運(yùn)行時(shí)之一(例如 containerd 或 CRI-O)，或者如果您依賴 Docker 引擎作為容器運(yùn)行時(shí)，則使用 cri-dockerd。

CSI卷健康監(jiān)控

能夠加載一個(gè)檢查持久卷健康狀況的sidecar是一個(gè)受歡迎的補(bǔ)充。現(xiàn)在，管理員將能夠更好、更快地對(duì) Kubernetes 外部刪除持久卷等事件做出反應(yīng)，必然會(huì)增加 Kubernetes 集群的可靠性。

kubelet：公開(kāi) OOM 指標(biāo)

從 1.24 開(kāi)始，kubelet提供了一個(gè)新的 Prometheus 指標(biāo)，用于記錄容器中發(fā)生的OOM(OutOfMemory)事件的數(shù)量。當(dāng)內(nèi)存限制不能滿足容器的使用和需求時(shí)，這提供了對(duì) Kubernetes 操作中反復(fù)出現(xiàn)的問(wèn)題的更多可見(jiàn)性。

使用這個(gè)新指標(biāo)，SRE 可以更好地了解問(wèn)題的最終原因，并更好地確定它是反復(fù)出現(xiàn)的問(wèn)題還是邊緣情況。更快的故障排除，更快樂(lè)的用戶。

Beta API 默認(rèn)關(guān)閉

之前的版本，默認(rèn)會(huì)啟用被認(rèn)為不穩(wěn)定的 Beta API，這加速了這些功能的采用，然而也會(huì)造成問(wèn)題。例如，一個(gè)測(cè)試版 API 有一個(gè)錯(cuò)誤，它將出現(xiàn)在 90% 的已部署集群上。

從 Kubernetes 1.24 開(kāi)始，新的 beta API 將默認(rèn)禁用。

選擇您想要的 LoadBalancer 類(lèi)型

在Kubernetes 1.24中，Service.Spec.LoadBalancerClass GA。

在托管 Kubernetes 集群中創(chuàng)建 LoadBalancer 類(lèi)型的服務(wù)會(huì)創(chuàng)建一個(gè)負(fù)載均衡器。Kubernetes 服務(wù)提供者負(fù)責(zé)創(chuàng)建這個(gè)負(fù)載均衡器。

通過(guò)這個(gè)LoadBalancerClass 字段，用戶可以指定他們想要的負(fù)載均衡器類(lèi)型，這將允許云提供商本地提供不同類(lèi)型的負(fù)載均衡器。到目前為止，主要依賴于注解或自定義控制器，這可能是笨重且違反直覺(jué)的：注解通常因提供者特定控制器的一個(gè)版本而異，希望這將使托管 Kubernetes 服務(wù)的用戶更容易聯(lián)網(wǎng)。

不推薦使用 Service.Spec.LoadBalancerIP 字段

說(shuō)到注解，Kubernetes 團(tuán)隊(duì)決定棄用Service.Spec.LoadBalancerIP 字段。原因是它沒(méi)有被詳細(xì)說(shuō)明，并且在不同的實(shí)現(xiàn)中具有不同的含義，也不支持需要 IPv4 和 IPv6 地址的雙棧Service。

官方建議提供者依賴注釋而不是該字段。

OpenAPI v3

Kubernetes 1.24 提供了以O(shè)penAPI v3 格式發(fā)布其 API 的 beta 支持。

存儲(chǔ)容量和卷擴(kuò)展普遍可用

存儲(chǔ)容量跟蹤支持通過(guò)CSIStorageCapacity 對(duì)象 公開(kāi)當(dāng)前可用的存儲(chǔ)容量， 并增強(qiáng)使用具有后期綁定的 CSI 卷的 pod 的調(diào)度。

卷擴(kuò)展增加了對(duì)調(diào)整現(xiàn)有持久卷大小的支持。

gRPC探針升級(jí)到 Beta

在Kubernetes 1.24 中，gRPC探測(cè)功能已進(jìn)入測(cè)試階段，默認(rèn)情況下可用。您現(xiàn)在可以在 Kubernetes 中為您的 gRPC 應(yīng)用程序本地配置啟動(dòng)、活動(dòng)和就緒探測(cè)，而無(wú)需公開(kāi) HTTP 端點(diǎn)或使用額外的可執(zhí)行文件。

服務(wù)帳戶默認(rèn)沒(méi)有Secret

只會(huì)影響使用 Kubernetes 存儲(chǔ)在 Secrets 中的長(zhǎng)期服務(wù)帳戶令牌的 Kubernetes 用戶。

在 Kubernetes 1.23 之前，在集群中創(chuàng)建服務(wù)帳戶會(huì)導(dǎo)致 Kubernetes 自動(dòng)為該服務(wù)帳戶創(chuàng)建一個(gè)帶有令牌的 Secret。此令牌永不過(guò)期，這可能很有用，但也是一個(gè)安全問(wèn)題。從 Kubernetes 1.24 開(kāi)始，這些 Secret 將不再自動(dòng)創(chuàng)建。

您可能會(huì)問(wèn)自己：該令牌不是安裝到使用該服務(wù)帳戶的 Pod 中嗎?不。創(chuàng)建新 Pod 時(shí)，kubelet 使用TokenRequest API為該 Pod 生成一個(gè)令牌，該令牌被掛載為一個(gè)投影卷。令牌在一小時(shí)后或 Pod 被刪除時(shí)過(guò)期，以先到者為準(zhǔn)。Kubelet 會(huì)定期更新令牌，因此 Pod 始終掛載有效令牌。

如果您絕對(duì)需要存儲(chǔ)在 Secret 中的永不過(guò)期令牌，您仍然可以通過(guò)自己創(chuàng)建 Secret 并添加特殊注釋來(lái)獲得。然后 Kubernetes 將為您將令牌添加到 Secret。

RuntimeClass.Overhead字段GA

使用默認(rèn)容器運(yùn)行時(shí)之外的原因有很多：運(yùn)行不受信任的工作負(fù)載或需要 GPU 的工作負(fù)載，僅舉幾例。Kubernetes 原生支持為這些用例定義自定義運(yùn)行時(shí)類(lèi)。

這些自定義運(yùn)行時(shí)可能會(huì)產(chǎn)生一些開(kāi)銷(xiāo)：運(yùn)行時(shí)本身而不是內(nèi)部運(yùn)行的容器使用 CPU 和內(nèi)存。RuntimeClass.Overhead 字段在Kubernetes 1.24 中達(dá)到普遍可用性，允許集群操作員指定此開(kāi)銷(xiāo)，以便 Kubernetes 在制定調(diào)度決策時(shí)將其考慮在內(nèi)。

其他值得關(guān)注的更新：

1. maxUnavailable for StatefulSets。
2. CronJobs支持TimeZone。
3. NetworkPolicyStatus。
4. 使用go 1.18.1構(gòu)建。
5. non-graceful node shutdown。

詳情參見(jiàn)

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md。