本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes v1.27: Chill Vibes

我們很高興地宣佈 Kubernetes v1.27 的釋出,這是 2023 年的第一個版本!

此版本包含 60 個增強功能。其中 18 個增強功能進入 Alpha 階段,29 個升級到 Beta 階段,13 個升級到穩定階段。

Kubernetes v1.27: Chill Vibes

Kubernetes v1.27 的主題是*放鬆一下 (Chill Vibes)*。

這個主題聽起來有點傻,但這次釋出中一些重要的轉變激發了這個主題。在一個典型的 Kubernetes 釋出週期中,特性需要滿足幾個最後期限才能被包含進來。如果某個特性錯過了任何一個最後期限,它們可以走一個例外流程。處理這些例外情況是釋出過程中的正常部分。但 v1.27 是所有人記憶中第一個在增強功能凍結後沒有收到任何例外請求的版本。即使在釋出過程中,事情也比我們任何人習慣的要平靜得多。

這次我們能夠享受一個更平靜的釋出,有一個特定的原因,那就是人們在幕後為改善我們管理釋出的方式所做的所有工作。這個主題正是為了慶祝那些為了讓社群變得更好而努力工作的人們。

特別感謝 Britnee Laverack 創作了這個徽標。Britnee 也為 Kubernetes 1.24: Stargazer 設計了徽標。

新功能(主要主題)

凍結 k8s.gcr.io 映象倉庫

舊的映象倉庫 k8s.gcr.io 將被 registry.k8s.io 替代,後者已經正式可用好幾個月了。Kubernetes 專案建立並執行著 registry.k8s.io 映象倉庫,該倉庫完全由社群控制。這意味著舊倉庫 k8s.gcr.io 將被凍結,Kubernetes 及相關子專案的映象將不再發布到舊倉庫。

這一變化對貢獻者意味著什麼?

  • 如果你是某個子專案的維護者,你需要更新你的清單(manifests)和 Helm charts 來使用新的倉庫。更多資訊,請檢視這個 專案

這一變化對終端使用者意味著什麼?

  • Kubernetes v1.27 版本將不會發布到 k8s.gcr.io 倉庫。

  • v1.24v1.25v1.26 的補丁版本在四月之後將不再發布到舊倉庫。

  • 從 v1.25 開始,預設的映象倉庫已經設定為 registry.k8s.io。這個值可以在 kubeadm 和 kubelet 中覆蓋,但是如果將其設定為 k8s.gcr.io,在四月之後的新版本中將會失敗,因為它們將不會存在於舊倉庫中。

  • 如果你想提高叢集的可靠性,並消除對社群所有倉庫的依賴,或者你在外部流量受限的網路中執行 Kubernetes,你應該考慮託管本地映象倉庫映象。一些雲供應商可能會為此提供託管解決方案。

SeccompDefault 畢業進入穩定版

要使用 seccomp 配置檔案預設設定,你必須在每個想要使用它的節點上,使用 --seccomp-default 命令列標誌來執行 kubelet。如果啟用,kubelet 將預設使用由容器執行時定義的 RuntimeDefault seccomp 配置檔案,而不是使用 Unconfined(seccomp 停用)模式。預設配置檔案旨在提供一組強大的安全預設設定,同時保留工作負載的功能。不同容器執行時及其釋出版本之間的預設配置檔案可能會有所不同。

你可以在相關的 Kubernetes 增強提案(KEP)中找到關於可能的升級和降級策略的詳細資訊:預設啟用 seccomp

Job 的可變排程指令進入正式釋出(GA)

這個功能在 v1.22 中引入,並以 Beta 級別開始,現在已穩定。在大多數情況下,並行 Job 希望 Pod 在有約束的條件下執行,比如都在同一個區域,或者都在 GPU 型號 x 或 y 上,但不能是兩者的混合。suspend 欄位是實現這些語義的第一步。suspend 允許自定義佇列控制器決定 Job 何時應該啟動。然而,一旦 Job 被取消掛起,自定義佇列控制器就無法影響 Job 的 Pod 實際會落在哪裡。

此功能允許在 Job 啟動前更新其排程指令,這使得自定義佇列控制器能夠影響 Pod 的放置,同時將實際的 Pod 到節點的分配工作交給 kube-scheduler。這僅適用於從未被取消掛起過的已掛起 Job。Job 的 Pod 模板中可以更新的欄位包括節點親和性、節點選擇器、容忍度、標籤、註解和排程門控(scheduling gates)。在 KEP 中查詢更多細節:允許更新 Job 的排程指令

DownwardAPIHugePages 畢業進入穩定版

在 Kubernetes v1.20 中,對 requests.hugepages-<pagesize>limits.hugepages-<pagesize> 的支援被新增到了 downward API 中,以與 cpu、記憶體和臨時儲存等其他資源保持一致。此功能在此版本中畢業進入穩定版。你可以在 KEP 中找到更多細節:Downward API HugePages

Pod 排程就緒進入 Beta 階段

建立後,Pod 就準備好進行排程了。Kubernetes 排程器會盡職盡責地尋找節點來放置所有待處理的 Pod。然而,在實際情況中,一些 Pod 可能會長時間處於*缺少必要資源*的狀態。這些 Pod 實際上會以不必要的方式攪動排程器(以及像 Cluster Autoscaler 這樣的下游整合者)。

透過指定/移除 Pod 的 .spec.schedulingGates,你可以控制 Pod 何時準備好被考慮進行排程。

schedulingGates 欄位包含一個字串列表,每個字串字面量被視為在 Pod 被認為可排程之前必須滿足的標準。該欄位只能在建立 Pod 時初始化(由客戶端,或在准入期間修改)。建立後,每個 schedulingGate 可以以任意順序移除,但不允許新增新的 scheduling gate。

透過 Kubernetes API 訪問節點日誌

此功能透過允許叢集管理員查詢在節點上執行的服務的日誌來幫助他們除錯問題。要使用此功能,請確保在該節點上啟用了 NodeLogQuery 功能門控,並且 kubelet 配置選項 enableSystemLogHandlerenableSystemLogQuery 都設定為 true。在 Linux 上,我們假設服務日誌可透過 journald 獲得。在 Windows 上,我們假設服務日誌在應用程式日誌提供程式中可用。你還可以分別從 Linux 和 Windows 上的 /var/log/C:\var\log 目錄中獲取日誌。

叢集管理員可以在其叢集的所有節點上或其中一部分節點上試用此 alpha 功能。

ReadWriteOncePod PersistentVolume 訪問模式進入 Beta 階段

Kubernetes v1.22PersistentVolumes (PVs) 和 PersistentVolumeClaims (PVCs) 引入了一種新的訪問模式 ReadWriteOncePod。此訪問模式使你能夠將卷訪問限制為叢集中的單個 Pod,確保一次只有一個 Pod 可以寫入該卷。這對於需要單寫入者訪問儲存的有狀態工作負載特別有用。

ReadWriteOncePod 的 Beta 版本增加了對使用 ReadWriteOncePod PVC 的 Pod 進行排程器搶佔的支援。排程器搶佔允許較高優先順序的 Pod 搶佔較低優先順序的 Pod。例如,當一個帶有 ReadWriteOncePod PVC 的 Pod (A) 被排程時,如果發現另一個 Pod (B) 正在使用相同的 PVC,並且 Pod (A) 具有更高的優先順序,排程器將返回一個 Unschedulable 狀態並嘗試搶佔 Pod (B)。更多背景資訊,請參見 KEP:ReadWriteOncePod PersistentVolume AccessMode

滾動升級後遵循 PodTopologySpread

matchLabelKeys 是一個 Pod 標籤鍵的列表,用於選擇將要計算分佈的 Pod。這些鍵用於從 Pod 標籤中查詢值。這些鍵值標籤與 labelSelector 進行邏輯與操作,以選擇將為傳入的 Pod 計算分佈的現有 Pod 組。在 Pod 標籤中不存在的鍵將被忽略。null 或空列表意味著只與 labelSelector 匹配。

有了 matchLabelKeys,使用者不需要在不同版本之間更新 pod.spec。控制器/操作員只需要為不同版本設定相同 label 鍵的不同值。排程器將根據 matchLabelKeys 自動假定這些值。例如,如果使用者使用 Deployment,他們可以使用由 Deployment 控制器自動新增的以 pod-template-hash 為鍵的標籤,來區分單個 Deployment 中的不同版本。

使用掛載加速 SELinux 卷重新標記

在這個版本中,將 SELinux 標籤應用於 Pod 使用的卷的方式正在升級到 Beta。此功能透過使用正確的 SELinux 標籤掛載捲來加速容器啟動,而不是遞迴地更改捲上的每個檔案。支援 SELinux 的 Linux 核心允許在首次掛載卷時使用 -o context= 掛載選項在整個捲上設定 SELinux 標籤。這樣,所有檔案都將在恆定時間內被分配給定的標籤,而無需遞迴遍歷整個卷。

context 掛載選項不能應用於繫結掛載或已掛載卷的重新掛載。對於 CSI 儲存,CSI 驅動程式執行卷的首次掛載,因此必須是 CSI 驅動程式實際應用此掛載選項。我們向 CSIDriver 物件添加了一個新欄位 SELinuxMount,以便驅動程式可以宣佈它們是否支援 -o context 掛載選項。

如果 Kubernetes 知道 Pod 的 SELinux 標籤**並且**負責 Pod 卷的 CSI 驅動程式宣佈 SELinuxMount: true **並且**該卷的訪問模式為 ReadWriteOncePod,那麼它將要求 CSI 驅動程式使用掛載選項 context= 掛載該卷**並且**它將告訴容器執行時不要重新標記卷的內容(因為所有檔案已經有了正確的標籤)。從 KEP 獲取更多關於此的資訊:使用掛載加速 SELinux 卷重新標記

健壯的 VolumeManager 重建進入 Beta 階段

這是一個卷管理器重構,允許 kubelet 在啟動期間填充關於現有卷如何掛載的額外資訊。總的來說,這使得卷清理更加健壯。如果你在節點上啟用 NewVolumeManagerReconstruction 功能門控,你將在 kubelet 啟動期間獲得對已掛載卷的增強發現。

在 Kubernetes v1.25 之前,kubelet 在啟動期間使用不同的預設行為來發現已掛載的卷。如果你停用此功能門控(預設啟用),你將選擇舊的發現行為。

在 Kubernetes v1.25 和 v1.26 中,此行為切換是 SELinuxMountReadWriteOncePod 功能門控的一部分。

可變的 Pod 排程指令進入 Beta 階段

這允許修改一個被排程就緒門控阻塞的 Pod,為其設定更嚴格的節點親和性/選擇器。它賦予了在 Pod 被允許排程之前修改其排程指令的能力,並使外部資源控制器能夠影響 Pod 的放置,同時將實際的 Pod 到節點分配工作交給 kube-scheduler。

這為在 Kubernetes 中新增排程功能的新模式打開了大門。具體來說,構建輕量級排程器,實現 kube-scheduler 不支援的功能,同時依賴現有的 kube-scheduler 來支援所有上游功能並處理 Pod 到節點的繫結。如果自定義功能不需要實現排程外掛(這需要重新構建和維護一個自定義的 kube-scheduler 二進位制檔案),那麼這種模式應該是首選。

Kubernetes v1.27 中的功能畢業和棄用

升級到穩定版

此版本包括總共 9 個晉升為穩定的增強功能

棄用和移除

此版本移除了幾項內容

釋出說明

Kubernetes v1.27 釋出的完整細節可在我們的釋出說明中找到。

可用性

Kubernetes v1.27 可在 GitHub 上下載。要開始使用 Kubernetes,你可以使用 minikubekind 等工具在本地執行 Kubernetes 叢集。你也可以使用 kubeadm 輕鬆安裝 v1.27。

釋出團隊

Kubernetes 的成功離不開其社群的支援、承諾和辛勤工作。每個釋出團隊都由敬業的社群志願者組成,他們共同努力,構建出你所依賴的 Kubernetes 版本的各個部分。這需要我們社群各個角落具有專業技能的人才,從程式碼本身到其文件和專案管理。

特別感謝我們的釋出負責人 Xander Grzywinski 引導我們度過了一個順利而成功的釋出週期,並感謝所有釋出團隊成員的相互支援和辛勤工作,為社群帶來了 v1.27 版本。

生態系統更新

  • KubeCon + CloudNativeCon Europe 2023 將於 2023 年 4 月 17 日至 21 日在荷蘭阿姆斯特丹舉行!你可以在活動網站上找到有關會議和註冊的更多資訊。
  • cdCon + GitOpsCon 將於 2023 年 5 月 8 日和 9 日在加拿大溫哥華舉行!有關會議和註冊的更多資訊,請訪問活動網站

專案速度

CNCF K8s DevStats 專案彙總了許多與 Kubernetes 和各種子專案速度相關的有趣資料點。這包括從個人貢獻到貢獻公司數量的所有內容,並展示了發展這個生態系統所付出的努力的深度和廣度。

在 v1.27 釋出週期中,該週期持續了 14 周(1月9日至4月11日),我們看到了來自 1020 家公司1603 名個人的貢獻。

即將舉行的釋出網路研討會

請在 2023 年 4 月 14 日星期五上午 10 點(太平洋夏令時)加入 Kubernetes v1.27 釋出團隊的成員,瞭解此版本的主要功能,以及棄用和移除的內容,以幫助規劃升級。更多資訊和註冊,請訪問 CNCF 線上專案網站上的活動頁面

參與其中

參與 Kubernetes 的最簡單方法是加入與你興趣相符的眾多特別興趣小組(SIG)之一。

有什麼想向 Kubernetes 社群廣播的內容嗎?在我們每週的社群會議上分享你的聲音,並透過以下渠道進行分享: