Kubernetes 1.16 釋出，一文讀懂其重磅新特性！

美國時間 9 月 18 日，Kubernetes 迎來了 2019 年的第三個新版本 1.16。根據 Release Note 介紹，Kubernetes v1.16 由 31 個增強功能組成：8 個進入穩定，8 個進入 Beta，15 個進入 Alpha。

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

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

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

核心主題

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

Custom resources ：CRD 是服務于一種新的資源類型，主要是對 Kubernetes 的一種擴充機制，目前已得到了廣泛的使用。自 1.7 版本以來，CRD 已經在 Beta 版中可用。在 1.16 版本中，CRD 正式步入通用可用性（GA）。
Admission Webhook ：Admission Webhooks 作為 Kubernetes 的擴充機制也被廣泛使用，并且自 1.9 版本以來已經在 Beta 版中可用。在 1.16 版本中，Admission Webhook 也正式步入通用可用性（GA）。
Overhauled metrics ：Kubernetes 之前廣泛使用一個全局 Metrics Registry 來注冊需要公開的各項名額。通過實作 Metrics Registry，Metrics 可以以更透明的方式注冊。而在這之前，各類穩定性要求都禁止使用 Kubernetes Metrics 。
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 增強開啟新的大門

Beta:增強 Windows 容器的工作負載辨別選項

Active Directory Group Managed Service Account (GMSA) 支援正在逐漸更新到beta版，而在 Alpha 版支援中的某些注釋将被棄用。

GMSA 是一種特定類型的 Active Directory 帳戶，允許 Windows 容器通過網絡傳輸身份辨別并與其他資源通信。

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

Alpha：使用 kubeadm 改進設定和節點連接配接體驗

引入對 kubeadm 的 alpha 支援，使 Kubernetes 使用者能夠輕松地将 Windows 工作節點加入（并重置）到現有叢集，操作方式與 Linux 節點一樣。

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

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 的傳輸（這足以填滿一張DVDCD光牒）。考慮到 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 功能，預設情況下不會啟用，但大家可以參閱說明文檔了解如何在叢集中啟用他們。

其他值得注意的功能更新

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

來源：靈雀雲

原文：http://j.mp/2Qj4WUc

題圖：來自谷歌圖檔搜尋

版權：本文版權歸原作者所有

投稿：歡迎投稿，郵箱: [email protected]