Kubernetes 1.17：穩定性

作者：Kubernetes 1.17 Release Team |

我們很高興宣布 Kubernetes 1.17 的交付，這是我們 2019 年的第四個也是最後一個版本！Kubernetes v1.17 包含 22 項增強功能：14 項增強功能已升級為穩定版，4 項增強功能正在轉移到 Beta 版，4 項增強功能正在進入 Alpha 版。

主要主題

雲端供應商標籤達到正式發布 (General Availability)

作為 v1.2 中新增的 Beta 功能，v1.17 見證了雲端供應商標籤的正式發布。

Volume Snapshot 移至 Beta 版

Kubernetes Volume Snapshot 功能現在在 Kubernetes v1.17 中為 Beta 版。它在 Kubernetes v1.12 中作為 Alpha 版推出，在 Kubernetes v1.13 中推出了第二個具有重大變更的 Alpha 版。

CSI 遷移 Beta 版

Kubernetes 內建儲存外掛程式到容器儲存介面 (CSI) 遷移基礎架構現在在 Kubernetes v1.17 中為 Beta 版。CSI 遷移在 Kubernetes v1.14 中作為 Alpha 版推出。

雲端供應商標籤達到正式發布 (General Availability)

當節點和磁碟區被建立時，會根據 Kubernetes 叢集底層的雲端供應商應用一組標準標籤。節點會獲得實例類型標籤。節點和磁碟區都會獲得兩個標籤，描述資源在雲端供應商拓撲中的位置，通常組織在區域 (zones) 和地區 (regions) 中。

Kubernetes 組件使用標準標籤來支援某些功能。例如，排程器將確保 pod 被放置在與它們聲明的磁碟區相同的區域中；並且在排程屬於部署的 pod 時，排程器將優先考慮將它們分散到各個區域。您也可以在您的 pod 規格中使用標籤來配置節點親和性之類的東西。標準標籤允許您編寫可在不同雲端供應商之間移植的 pod 規格。

標籤在此版本中達到正式發布。Kubernetes 組件已更新為填充正式發布和 Beta 標籤，並對兩者做出反應。但是，如果您在 pod 規格中使用 Beta 標籤來實現節點親和性等功能，或在您的自訂控制器中使用 Beta 標籤，我們建議您開始將它們遷移到新的正式發布標籤。您可以在此處找到新標籤的文件

Volume Snapshot 移至 Beta 版

Kubernetes Volume Snapshot 功能現在在 Kubernetes v1.17 中為 Beta 版。它在 Kubernetes v1.12 中作為 Alpha 版推出，在 Kubernetes v1.13 中推出了第二個具有重大變更的 Alpha 版。這篇文章總結了 Beta 版中的變更。

什麼是 Volume Snapshot？

許多儲存系統（例如 Google Cloud Persistent Disks、Amazon Elastic Block Storage 和許多地端部署儲存系統）都提供了建立持久磁碟區「快照」的能力。快照表示磁碟區在特定時間點的副本。快照可用於佈建新的磁碟區（預先填充快照資料）或將現有磁碟區還原到先前的狀態（由快照表示）。

為何將 Volume Snapshot 新增到 Kubernetes？

Kubernetes 磁碟區外掛程式系統已經提供了一個強大的抽象層，可以自動化區塊和檔案儲存的佈建、附加和掛載。

所有這些功能的基礎是 Kubernetes 工作負載可移植性的目標：Kubernetes 旨在在分散式系統應用程式和底層叢集之間建立一個抽象層，以便應用程式可以與它們運行的叢集的具體細節無關，並且應用程式部署不需要「叢集特定」的知識。

Kubernetes Storage SIG 認為快照操作是許多具狀態工作負載的關鍵功能。例如，資料庫管理員可能希望在啟動資料庫操作之前對資料庫磁碟區進行快照。

透過在 Kubernetes API 中提供觸發快照操作的標準方式，Kubernetes 使用者現在可以處理這樣的用例，而無需繞過 Kubernetes API（並手動執行儲存系統特定的操作）。

相反地，Kubernetes 使用者現在可以將快照操作以與叢集無關的方式整合到他們的工具和政策中，並且可以放心地知道它將針對任意 Kubernetes 叢集工作，而與底層儲存無關。

此外，這些 Kubernetes 快照基本元素充當基本的建構區塊，可解鎖為 Kubernetes 開發進階、企業級儲存管理功能的能力：包括應用程式或叢集級別的備份解決方案。

您可以在關於將 CSI 磁碟區快照發布到 Beta 版的網誌文章中閱讀更多內容。

CSI 遷移 Beta 版

為何我們要將內建外掛程式遷移到 CSI？

在 CSI 之前，Kubernetes 提供了一個強大的磁碟區外掛程式系統。這些磁碟區外掛程式是「內建的」，意味著它們的程式碼是核心 Kubernetes 程式碼的一部分，並與核心 Kubernetes 二進位檔案一起發布。然而，為 Kubernetes 新增對新磁碟區外掛程式的支援具有挑戰性。想要為其儲存系統新增對 Kubernetes 支援（甚至修復現有磁碟區外掛程式中的錯誤）的供應商被迫與 Kubernetes 發布流程保持一致。此外，第三方儲存程式碼在核心 Kubernetes 二進位檔案中引起了可靠性和安全性問題，並且 Kubernetes 維護人員通常難以（在某些情況下甚至不可能）測試和維護該程式碼。在 Kubernetes 中使用容器儲存介面解決了這些主要問題。

隨著更多 CSI 驅動程式被建立並變得適用於生產環境，我們希望所有 Kubernetes 使用者都能獲得 CSI 模型的優勢。但是，我們不想透過破壞現有的正式發布儲存 API 來強迫使用者進行工作負載/組態變更。前進的道路很明確 - 我們必須用 CSI 替換「內建外掛程式」API 的後端。什麼是 CSI 遷移？

CSI 遷移工作使替換現有的內建儲存外掛程式（例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs）及其對應的 CSI 驅動程式成為可能。如果 CSI 遷移運作正常，Kubernetes 終端使用者不應注意到任何差異。遷移後，Kubernetes 使用者可以繼續使用現有介面來依賴內建儲存外掛程式的所有功能。

當 Kubernetes 叢集管理員更新叢集以啟用 CSI 遷移時，現有的具狀態部署和工作負載將繼續像往常一樣運作；但是，在幕後，Kubernetes 將所有儲存管理操作（先前針對內建驅動程式）的控制權移交給 CSI 驅動程式。

Kubernetes 團隊一直努力確保儲存 API 的穩定性，並承諾提供順暢的升級體驗。這涉及對所有現有功能和行為進行細緻的核算，以確保向後相容性和 API 穩定性。您可以將其視為在賽車以全速衝刺時更換車輪。

您可以在關於CSI 遷移進入 Beta 版的網誌文章中閱讀更多內容。

其他更新

升級為穩定版 💯

重大變更

其他值得注意的功能

可用性

Kubernetes 1.17 可在 GitHub 上下載。要開始使用 Kubernetes，請查看這些互動式教學課程。您也可以使用 kubeadm 輕鬆安裝 1.17。

發布團隊

此版本的發布歸功於數百名貢獻技術和非技術內容的個人的努力。特別感謝由 Guinevere Saenger 領導的發布團隊。發布團隊的 35 位成員協調了發布的許多方面，從文件編寫到測試、驗證和功能完整性。

隨著 Kubernetes 社群的成長，我們的發布流程代表了開放原始碼軟體開發中協作的驚人示範。Kubernetes 繼續以快速的速度獲得新使用者。這種成長創造了一個正向回饋循環，更多的貢獻者提交程式碼，創造了一個更充滿活力的生態系統。Kubernetes 迄今為止已擁有超過 39,000 名個人貢獻者和超過 66,000 人的活躍社群。

網路研討會

加入 Kubernetes 1.17 發布團隊成員於 2020 年 1 月 7 日舉行的網路研討會，以了解此版本中的主要功能。在此註冊。

參與其中

參與 Kubernetes 最簡單的方式是加入與您的興趣相符的眾多特殊興趣小組 (SIG) 之一。有想向 Kubernetes 社群廣播的內容嗎？在我們的每週社群會議上以及透過以下管道分享您的聲音。感謝您持續的回饋和支持。