Kubernetes 1.16 發布，一文讀懂其重磅新特性！

• 2019 年 10 月 6 日
• 筆記

此次發行版源自數百名技術與非技術貢獻者的共同努力，隨著 Kubernetes 社區的不斷發展，我們的發布過程也代表著開源軟體開發協作領域的又一驚人成功。

Kubernetes 仍在不斷獲得新用戶，快速成長本身則創造出積極回饋周期，吸引更多貢獻者提交程式碼，最終建立起強大且極具活力的社區群體。截至目前，Kubernetes 擁有超過 32000 名個人貢獻者，社區成員總量則超過 66000 人。

這裡，我們整理了 Kubernetes 1.16 的亮點內容詳細介紹給大家。

核心主題

Kubernetes 1.16 新版本中主要更新了以下幾個核心內容。

1. Custom resources：CRD 是服務於一種新的資源類型，主要是對 Kubernetes 的一種擴展機制，目前已得到了廣泛的使用。自 1.7 版本以來，CRD 已經在 Beta 版中可用。在 1.16 版本中，CRD 正式步入通用可用性（GA）。
2. Admission Webhook：Admission Webhooks 作為 Kubernetes 的擴展機制也被廣泛使用，並且自 1.9 版本以來已經在 Beta 版中可用。在 1.16 版本中，Admission Webhook 也正式步入通用可用性（GA）。
3. Overhauled metrics：Kubernetes 之前廣泛使用一個全局 Metrics Registry 來註冊需要公開的各項指標。通過實現 Metrics Registry，Metrics 可以以更透明的方式註冊。而在這之前，各類穩定性要求都禁止使用 Kubernetes Metrics 。
4. Volume Extension：新版本中有很多與 Volume 和 Volume 修改相關的增強功能。CSI 規範中的 Volume 調整支援正在轉向 Beta 版，它允許任何 CSI 規範的 Volume Plugin 都可以調整大小。

其他增強

自定義資源達到通用可用性

CRD 已經成為 Kubernetes 生態系統擴展的基礎。從重新設計第三方資源原型開始，最終在 1.16 中通過 apiextensions.k8s.io/v1 實現了 GA，且整合了大量 Kubernetes 發展過程中積累的 API 相關演化經驗。當轉換到 GA 時，我們的首要重點是 API 客戶端的數據一致性。

當您升級到 GA API 時，您會注意到一些以前可選的護欄已經成為必需的或默認的行為。比如結構模式、刪除未知欄位、驗證和保護 *.k8.io 組對於確保 API 的使用壽命非常重要，而且現在更難以意外遺漏。

default 是 API 演化的另一個重要部分，默認情況下，CRD.v1 將啟用該支援。這些以及 CRD 轉換機制的組合足以構建隨時間演變的穩定 API，就像 Kubernetes 本地資源在不破壞向後兼容性的情況下發生了變化一樣。

CRD API 的更新不會就此結束。我們對任意子資源、API 組遷移以及更高效的序列化協議等特性都有一些想法，但是這裡的變化本質上是可選的，並且與 GA API 中已有的特性互補。

利用 Windows 增強開啟新的大門

1. Beta:增強 Windows 容器的工作負載標識選項

Active Directory Group Managed Service Account (GMSA) 支援正在逐步升級到beta版，而在 Alpha 版支援中的某些注釋將被棄用。

GMSA 是一種特定類型的 Active Directory 帳戶，允許 Windows 容器通過網路傳輸身份標識並與其他資源通訊。

Windows 容器現在可以通過身份驗證訪問外部資源。此外，GMSA 還提供了自動密碼管理、簡化的服務主體名稱 (SPN) 管理以及跨多個伺服器將管理委託給其他管理員的能力。

1. Alpha：使用 kubeadm 改進設置和節點連接體驗

引入對 kubeadm 的 alpha 支援，使 Kubernetes 用戶能夠輕鬆地將 Windows 工作節點加入（並重置）到現有集群，操作方式與 Linux 節點一樣。

用戶可以使用 kubeadm 來準備和添加 Windows 節點到群集。操作完成後，該節點將處於 Ready 狀態並能夠運行 Windows 容器。此外，我們還將提供一組 Windows 的特定腳本，旨在配合節點添加的其它資源與 CNI 安裝需求。

1. Alpha:引入對容器存儲介面 (CSI) 的支援

引入對樹外提供者的 CSI 插件支援，使 Kubernetes 集群中的 Windows 節點能夠利用持久存儲功能運行基於 Windows 的工作負載。

這極大地擴展了 Windows 工作負載的存儲選項，使用戶能在 FlexVolume 和 in-tree 存儲插件之外擁有新的選擇。此功能通過主機 OS 代理實現，該代理支援代理容器在 Windows 節點上執行特權操作。

引入 Endpoint 切片

Kubernetes 1.16 版本還包含一項令人興奮的全新 Alpha 功能：Endpoint 切片。這為 Endpoint 資源提供了一個可伸縮和可擴展的替代方案。在後端，這些資源在 Kubernetes 內部的網路路由中扮演著重要的角色。

每個網路 Endpoint 都在這些資源中受到追蹤，kube-proxy 利用如上 Endpoint 生成代理規則，允許 Pod 在 Kubernetes 中如此輕鬆地相互通訊。

提供更強大的可擴展性

Endpoint 切片的一個關鍵目標是為 Kubernetes 服務提供更強大的可擴展性。對於現有 Endpoint資源，單個資源必須包含表示與某項服務相關聯的所有 Pod 的網路 Endpoint。

隨著服務擴展至數千個 Pod，相應的 Endpoint 資源變得非常大。如果簡單地對服務添加或刪除一個Endpoint 可能帶來可觀的成本。

隨著 Endpoint 資源的更新，程式碼中與該 Endpoint 相關的部分都需要獲取一份關於該資源的完整副本。群集中的每個節點運行 kube-proxy 時，需要將副本發送到每個節點。在小範圍內，這不是問題，但隨著集群變大，影響會變得越來越明顯。

比如，在一個擁有 5,000 個節點和 1MB Endpoint 對象的集群中，任何更新都會導致大約 5GB 的傳輸（這足以填滿一張DVD光碟）。考慮到 Endpoint 在部署期間頻繁滾動更新等事件，這將是一筆巨大的資源浪費。

使用 Endpoint 切片，服務的網路 Endpoint 可以拆分為多個資源，從而顯著減少大規模更新所需的數據量。默認情況下，每個 Endpoint 切片最多包含 100 個 Endpoint。

例如，我們擁有 20,000 個網路 Endpoint，分布在擁有 5,000 個節點的集群上。利用 Endpoint 切片更新單個 Endpoint 的效率會更高，因為每個 Endpoint 僅包含網路 Endpoint 總數的一小部分。

相較於以往將大 Endpoint 對象傳輸至各個節點的方式，現在我們只需要傳輸已經變更的小型 Endpoint 切片。實際效果就是，現在更新操作的數據傳輸量僅相當於以往的約二百分之一。

Endpoint 切片的第二個主要目標，是提供一種在各種用例中具有高度可擴展性和實用性的資源。Endpoint 切片的一個關鍵添加還涉及新的拓撲屬性。默認情況下，這將填充 Kubernetes 中使用的現有拓撲標籤，用以指示 region 與 zone 等屬性。當然，這個欄位也可以填充自定義標籤以及更專業的用例。

Endpoint 切片還實現了更大的地址類型靈活性。每個都包含一個地址列表。多地址初始用例同時支援具有 IPv4 和 IPv6 地址的雙棧 Endpoint。

Kubernetes 文檔提供了有關 Endpoint 切片的更多資訊。作為 Kubernetes 1.16 中的 Alpha 功能，默認情況下不會啟用，但大家可以參閱說明文檔了解如何在集群中啟用他們。

其他值得注意的功能更新

1. Topology Manager 拓撲管理器是一種新的 Kubelet 組件，旨在協調資源分配決策，以提供優化的資源分配；
2. IPv4 / IPv6 雙棧可以將 IPv4 和 IPv6 地址分配給 Pod 和 Service；
3. Cloud Controller Manager Migration提供更多遷移擴展選項；
4. 繼續棄用 extensions/v1beta1，apps/v1beta1 和 apps/v1beta2 API。這些擴展已在 1.16 中遭到淘汰！

來源：靈雀雲 原文：http://j.mp/2Qj4WUc 題圖：來自Google圖片搜索 版權：本文版權歸原作者所有 投稿：歡迎投稿，郵箱: [email protected]