一文看懂Kubernetes v1.16！

2019 年 10 月 6 日
筆記

Kubernetes 1.16 徽章

靈感源自阿波羅16號任務徽章

譯者：小靈

技術校對：oilbeater

9月18日，Kubernetes v1.16重磅發布！這是2019年以來發布的第三個版本! Kubernetes 1.16包含31個增強功能：8個增強趨於穩定，8個進入beta版，15個在alpha版。

主題

1. Custom resources：CRD作為Kubernetes的擴展機製得到了廣泛的使用，並且從1.7版本開始就已經在beta版中可用。1.16版本標誌著CRDs正式進入通用可用性(GA)

2.Overhauled metrics：Kubernetes之前廣泛使用一個全局metrics registry來註冊要公開的metrics。通過實現metrics registry，metrics以更透明的方式註冊。以前，Kubernetes metrics被排除在任何類型的穩定性需求之外。

3.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中已有的特性互補。

有關如何使用自定義資源的詳細資訊，請參閱Kubernetes文檔。

利用Windows增強開啟新的大門

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

Active Directory Group Managed Service Account(GMSA)支援正在逐步升級到beta版，而在alpha版支援中的某些注釋將被棄用。GMSA是一種特定類型的Active Directory帳戶，允許Windows容器通過網路傳輸身份標識並與其他資源通訊。Windows容器現在可以通過身份驗證訪問外部資源。此外，GMSA還提供了自動密碼管理、簡化的服務主體名稱(SPN)管理以及跨多個伺服器將管理委託給其他管理員的能力。

在alpha版本中，我們添加了對RunAsUserName的支援。RunAsUserName是一個字元串，指定windows中的windows標識(或用戶名)來運行容器的入口點，它同時也是securityContext (WindowsSecurityContextOptions)新引入的windowsOptions組件的一部分。

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的傳輸（這足以填滿一張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功能，默認情況下不會啟用，但大家可以參閱說明文檔了解如何在集群中啟用他們。

其他值得注意的功能更新

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

相關鏈接：

https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement/

Tags: