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

Kubernetes 1.16：自定義資源、全面改進的指標和卷擴充套件

由 Kubernetes 1.16 釋出團隊 | 2019 年 9 月 18 日星期三

我們很高興地宣佈 Kubernetes 1.16 釋出，這是我們 2019 年的第三個版本！Kubernetes 1.16 包含 31 項增強功能：8 項增強功能進入穩定版，8 項增強功能進入測試版，15 項增強功能進入 Alpha 版。

主要主題

自定義資源

CRD 作為 Kubernetes 擴充套件機制被廣泛使用，自 1.7 版本以來已提供測試版。1.16 版本標誌著 CRD 達到普遍可用性 (GA)。

指標大修

Kubernetes 以前廣泛使用全域性指標註冊表來註冊要公開的指標。透過實現指標註冊表，指標以更透明的方式註冊。以前，Kubernetes 指標被排除在任何穩定性要求之外。

卷擴充套件

此版本中有許多與卷和卷修改相關的增強功能。CSI 規範中的卷大小調整支援正在進入 Beta 版，這允許任何 CSI 規範卷外掛可調整大小。

Kubernetes API 的重大變更

隨著 Kubernetes API 的發展，我們已經將一些 API 資源提升為 *穩定* 版，其他的則被重新組織到不同的組中。我們根據 API 版本控制策略棄用舊版本的資源並提供新版本。

一個例子是 Deployment 資源。它在 1.6 中以 extensions/v1beta1 組引入，隨著專案的變化，被提升到 extensions/v1beta2、apps/v1beta2，最後在 1.9 中提升為 stable 並移至 apps/v1。

值得注意的是，直到此版本，該專案都沒有停止提供任何已棄用資源的任何先前版本。

這意味著與 Kubernetes API 互動的人員 **不** 需要遷移到任何已棄用 API 物件的新版本。

在 1.16 中，如果您將 Deployment 提交到 API 伺服器並指定 extensions/v1beta1 作為 API 組，它將被拒絕，並顯示

error: unable to recognize "deployment": no matches for kind "Deployment" in version "extensions/v1beta1"

在此版本中，我們正在邁出 Kubernetes API 成熟度的非常重要的一步，並且不再提供已棄用的 API。我們早期的文章 1.16 中移除的已棄用 API：您需要了解的內容告訴您更多資訊，包括哪些資源受到影響。

其他增強功能

自定義資源達到普遍可用性

CRD 已成為 Kubernetes 生態系統擴充套件的基礎。它們最初是第三方資源原型的重新設計，在 1.16 中最終達到了 GA，版本為 apiextensions.k8s.io/v1，其中整合了 Kubernetes API 演進的來之不易的經驗教訓。隨著我們過渡到 GA，重點是 API 客戶端的資料一致性。

當您升級到 GA API 時，您會注意到之前的一些可選護欄已成為必需和/或預設行為。結構化模式、修剪未知欄位、驗證以及保護 *.k8s.io 組對於確保您的 API 的壽命至關重要，現在更難意外遺漏。預設是 API 演進的另一個重要部分，並且該支援將預設用於 CRD.v1。這些功能與 CRD 轉換機制相結合，足以構建隨時間演進的穩定 API，就像原生 Kubernetes 資源在不破壞向後相容性的情況下發生變化一樣。

CRD API 的更新不會就此結束。我們有關於任意子資源、API 組遷移以及可能更高效的序列化協議等功能的想法，但從這裡開始的更改預計將是可選的，並且與 GA API 中已有的功能互補。祝您操作愉快！

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

透過 Windows 增強功能開啟大門

Beta：增強 Windows 容器的工作負載身份選項

Active Directory 組管理服務帳戶 (GMSA) 支援正在升級到 Beta 版，並且隨著 Alpha 支援引入的某些註釋正在被棄用。GMSA 是一種特定型別的 Active Directory 帳戶，它使 Windows 容器能夠在網路中攜帶身份並與其他資源進行通訊。Windows 容器現在可以獲得對外部資源的經過身份驗證的訪問。此外，GMSA 還提供自動密碼管理、簡化的服務主體名稱 (SPN) 管理，以及將管理委託給多個伺服器上的其他管理員的能力。

新增對 RunAsUserName 的 Alpha 版支援。RunAsUserName 是一個字串，指定 Windows 中的 Windows 身份（或使用者名稱）以執行容器的入口點，並且是 securityContext (WindowsSecurityContextOptions) 新引入的 windowsOptions 元件的一部分。

Alpha：使用 kubeadm 改進設定和節點加入體驗

引入對 kubeadm 的 Alpha 支援，使 Kubernetes 使用者能夠以與 Linux 節點相同的方式輕鬆地將 Windows worker 節點加入（和重置）到現有叢集。使用者可以使用 kubeadm 準備並將 Windows 節點新增到叢集。操作完成後，節點將處於“就緒”狀態並能夠執行 Windows 容器。此外，我們還將提供一套 Windows 特定的指令碼，以便在節點加入叢集之前安裝先決條件和 CNI。

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

為樹外提供商引入 CSI 外掛支援，使 Kubernetes 叢集中的 Windows 節點能夠利用基於 Windows 的工作負載的持久儲存功能。這大大擴充套件了 Windows 工作負載的儲存選項，增加了 FlexVolume 和樹記憶體儲外掛列表。此功能透過主機作業系統代理實現，該代理允許代表容器在 Windows 節點上執行特權操作。

引入 Endpoint Slices

Kubernetes 1.16 釋出包含一個激動人心的新 Alpha 功能：EndpointSlice API。此 API 提供了一個可擴充套件且可伸縮的替代方案，取代了可以追溯到 Kubernetes 最早版本的 Endpoints 資源。在幕後，Endpoints 在 Kubernetes 內部的網路路由中扮演著重要角色。每個 Service 端點都透過這些資源進行跟蹤——kube-proxy 使用它們來生成代理規則，從而使 Pod 能夠在 Kubernetes 中如此輕鬆地相互通訊，並且許多 Ingress 控制器使用它們將 HTTP 流量直接路由到 Pod。

提供更高的可擴充套件性

EndpointSlices 的一個關鍵目標是為 Kubernetes Service 提供更高的可擴充套件性。使用現有的 Endpoints API，單個例項必須包含表示與 Service 匹配的所有 Pod 的網路端點。隨著 Service 擴充套件到數千個 Pod，相應的 Endpoints 資源變得相當大。在這種規模下，簡單地從 Service 中新增或刪除一個端點可能會非常昂貴。隨著 Endpoints 例項的更新，每個觀察 Endpoints 的程式碼都需要傳送該資源的完整副本。由於 kube-proxy 在叢集中的每個節點上執行，因此需要將副本傳送到每個節點。在小規模下，這不是問題，但隨著叢集變大，它會越來越明顯。

Endpoints to Endpoint Slice

使用 EndpointSlices，Service 的網路端點被拆分為多個例項，顯著減少了大規模更新所需的資料量。預設情況下，每個 EndpointSlice 限制為 100 個端點。

例如，我們假設一個叢集有 10,000 個 Service 端點分佈在 5,000 個節點上。單個 Pod 更新將導致使用 Endpoints API 傳輸大約 5GB 的資料（這足以裝滿一張 DVD）。考慮到在滾動更新 Deployment 等事件期間 Endpoints 更改的頻率，這變得越來越重要。使用 EndpointSlices 進行相同的更新將更有效率，因為每個 EndpointSlice 只包含 Service 端點總數的一小部分。無需將一個大的 Endpoints 物件傳輸到每個節點，只需傳輸已更改的小 EndpointSlice。在此示例中，EndpointSlices 將使傳輸的資料量減少大約 100 倍。

	端點	端點切片
資源數量	1	20k / 100 = 200
儲存的網路端點數量	1 20k = 20k*	200 100 = 20k*
每個資源的大小	20k 常量 = ~2.0 MB*	100 常量 = ~10 kB*
監視事件傳輸的資料	~2.0MB 5k = 10GB*	~10kB 5k = 50MB*

提供更大的可擴充套件性

EndpointSlices 的第二個目標是提供一種高度可擴充套件且適用於各種用例的資源。EndpointSlices 的一個關鍵新增功能是新的拓撲屬性。預設情況下，這將填充 Kubernetes 中用於指示區域和可用區等屬性的現有拓撲標籤。當然，此欄位也可以填充自定義標籤，以用於更專業的用例。

EndpointSlices 還為地址型別提供了更大的靈活性。每個都包含一個地址列表。多個地址的最初用例是支援 IPv4 和 IPv6 地址的雙棧端點。例如，這是一個簡單的 EndpointSlice，展示瞭如何表示一個 EndpointSlice

apiVersion: discovery.k8s.io/v1alpha
kind: EndpointSlice
metadata:
  name: example-abc
  labels:
    kubernetes.io/service-name: example
addressType: IP
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
    - "10.1.2.3"
    - "2001:db8::1234:5678"
    topology:
      kubernetes.io/hostname: node-1
      topology.kubernetes.io/zone: us-west2-a

可用性

Kubernetes 1.16 可在 GitHub 上下載。要開始使用 Kubernetes，請檢視這些互動式教程。您還可以使用 kubeadm 輕鬆安裝 1.16。

釋出團隊

本次釋出得益於數百位個人貢獻者在技術和非技術內容方面的努力。特別感謝由微軟首席專案經理 Lachlan Evenson 領導的釋出團隊。釋出團隊的 32 名成員協調了釋出的許多方面，從文件到測試、驗證和功能完整性。

隨著 Kubernetes 社群的發展，我們的釋出過程代表了開源軟體開發中協作的驚人示範。Kubernetes 繼續以快速的速度獲得新使用者。這種增長創造了一個積極的反饋迴圈，即更多的貢獻者提交程式碼，從而建立了一個更活躍的生態系統。迄今為止，Kubernetes 已經擁有超過 32,000 名個人貢獻者，並擁有一個超過 66,000 人的活躍社群。

釋出吉祥物

Kubernetes 1.16 的釋出徽章鬆散地受到阿波羅 16 號任務徽章的啟發。它代表了釋出團隊和社群的辛勤工作，也是對我們在整個釋出週期中作為團隊共同經歷的挑戰和歡樂時光的頌歌。非常感謝微軟的 Ronan Flynn-Curran 創作了這件宏偉的作品。

Kubernetes 1.16 Release Mascot

Kubernetes 更新

專案速度

CNCF 繼續完善 DevStats，這是一個雄心勃勃的專案，旨在視覺化對該專案的大量貢獻。 K8s DevStats 展示了主要公司貢獻者的貢獻細分，以及一系列令人印象深刻的預配置報告，涵蓋從個人貢獻者到拉取請求生命週期時間的所有內容。過去一年，每月有 1,147 家不同的公司和超過 3,149 名個人為 Kubernetes 做出貢獻。檢視 DevStats 瞭解有關 Kubernetes 專案和社群整體速度的更多資訊。

生態系統

Kubernetes 專案領導層成立了安全審計工作組，負責監督首次第三方 Kubernetes 安全審計，以提高整個生態系統的安全性。
Kubernetes 認證服務提供商 (KCSP) 計劃已達到 100 家成員公司，涵蓋從最大的跨國雲、企業軟體和諮詢公司到小型初創企業。
首份 Kubernetes 專案歷程報告釋出，展示了該專案的巨大增長。

KubeCon + CloudNativeCon

Cloud Native Computing Foundation 的旗艦會議將於 2019 年 11 月 18 日至 21 日在加利福尼亞州聖地亞哥舉行，彙集了來自領先開源和雲原生社群的採用者和技術專家。加入 Kubernetes、Prometheus、Envoy、CoreDNS、containerd、Fluentd、OpenTracing、gRPC、CNI、Jaeger、Notary、TUF、Vitess、NATS、Linkerd、Helm、Rook、Harbor、etcd、Open Policy Agent、CRI-O 和 TiKV，社群將齊聚一堂，為期四天，以促進雲原生計算的教育和進步。立即註冊！

網路研討會

請於 2019 年 10 月 22 日加入 Kubernetes 1.16 釋出團隊成員，瞭解此版本中的主要功能。在此註冊。

參與其中

參與 Kubernetes 最簡單的方法是加入眾多與您的興趣相關的特別興趣小組 (SIG)。有什麼想向 Kubernetes 社群廣播的嗎？在我們的每週社群會議上以及透過以下渠道分享您的聲音。感謝您一直以來的反饋和支援。

在 Twitter 上關注我們 @Kubernetesio 獲取最新更新
在 Discuss 上加入社群討論
在 Slack 上加入社群
在 Stack Overflow 上提問（或回答問題）
分享你的 Kubernetes 故事

Kubernetes 部落格