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

Kubernetes 1.16:自訂資源、全面檢修的指標和卷擴展

我們很高興宣布 Kubernetes 1.16 的發布,這是我們 2019 年的第三個版本! Kubernetes 1.16 包含 31 項增強功能:8 項增強功能升級至穩定版,8 項增強功能處於 Beta 版,以及 15 項增強功能處於 Alpha 版。

主要主題

自訂資源

CRD 作為 Kubernetes 擴展機制被廣泛使用,自 1.7 版本以來已在 Beta 版中提供。 1.16 版本標誌著 CRD 升級至正式發行版 (GA)。

全面檢修的指標

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

磁碟區擴展

此版本中有許多與磁碟區和磁碟區修改相關的增強功能。 CSI 規格中的磁碟區調整大小支援正在轉移到 Beta 版,這允許任何 CSI 規格磁碟區外掛程式可調整大小。

Kubernetes API 的重大變更

隨著 Kubernetes API 的發展,我們已將一些 API 資源升級為穩定版,其他資源已重新組織到不同的群組。 我們根據 API 版本控制政策 棄用舊版本的資源並提供較新版本。

其中一個例子是 Deployment 資源。 這是在 1.6 中在 extensions/v1beta1 群組下引入的,並且隨著專案的變更,已升級到 extensions/v1beta2apps/v1beta2,並最終升級到 stable 並在 1.9 中移動到 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 生態系統中擴展的基礎。 作為 ThirdPartyResources 原型的從頭開始重新設計,它們最終在 1.16 中透過 apiextensions.k8s.io/v1 達到 GA,因為 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 使用者能夠輕鬆地將 Windows 工作節點加入(和重設)到現有叢集,就像他們對 Linux 節點所做的那樣。 使用者可以利用 kubeadm 來準備 Windows 節點並將其新增到叢集中。 操作完成後,節點將處於就緒狀態,並且能夠執行 Windows 容器。 此外,我們還將提供一組特定於 Windows 的腳本,以在將節點加入叢集之前啟用先決條件和 CNI 的安裝。

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

引入對樹狀結構外部提供者的 CSI 外掛程式支援,使 Kubernetes 叢集中的 Windows 節點能夠利用 Windows 工作負載的持久儲存功能。 這顯著擴展了 Windows 工作負載的儲存選項,添加到包含 FlexVolume 和樹狀結構內儲存外掛程式的列表中。 此功能是透過主機作業系統代理實現的,該代理啟用在 Windows 節點上代表容器執行特權操作。

引入端點切片

Kubernetes 1.16 的發布包含一個令人興奮的新 Alpha 版功能:EndpointSlice API。 此 API 提供了一種可擴展且可擴充的替代方案,可替代 Endpoints 資源,該資源可以追溯到 Kubernetes 的最早版本。 在幕後,Endpoints 在 Kubernetes 內的網路路由中扮演著重要角色。 每個服務端點都在這些資源中追蹤 — kube-proxy 使用它們來產生 Proxy 規則,這些規則允許 Pod 在 Kubernetes 中輕鬆地相互通訊,並且許多 Ingress 控制器使用它們將 HTTP 流量直接路由到 Pod。

提供更高的擴展性

EndpointSlices 的主要目標是為 Kubernetes 服務啟用更高的擴展性。 使用現有的 Endpoints API,單個實例必須包含代表與服務匹配的所有 Pod 的網路端點。 隨著服務開始擴展到數千個 Pod,相應的 Endpoints 資源變得非常龐大。 在此規模下,僅僅從服務中新增或移除一個端點可能會非常耗費成本。 隨著 Endpoints 實例的更新,每個監看 Endpoints 的程式碼片段都需要傳送資源的完整副本。 由於 kube-proxy 在叢集中的每個節點上執行,因此需要將副本傳送到每個節點。 在小規模下,這不是問題,但隨著叢集變得更大,它變得越來越明顯。

Endpoints to Endpoint Slice

使用 EndpointSlices,服務的網路端點被分成多個實例,顯著減少了大規模更新所需資料量。 預設情況下,EndpointSlices 每個限制為 100 個端點。

例如,讓我們以一個在 5,000 個節點上分散了 10,000 個服務端點的叢集為例。 單個 Pod 更新將導致使用 Endpoints API 傳輸約 5GB(足以填滿 DVD)。 鑑於在 Deployment 上的滾動更新等事件期間 Endpoints 可能會頻繁變更,這一點變得越來越重要。 使用 EndpointSlices,相同的更新將更有效率,因為每個 EndpointSlice 僅包含服務端點總數的一小部分。 無需將大型 Endpoints 物件傳輸到每個節點,只需傳輸已變更的小型 EndpointSlice 即可。 在此範例中,EndpointSlices 將減少約 100 倍的資料傳輸量。

端點 (Endpoints)端點切片 (Endpoint Slices)
# 資源數量120k / 100 = 200
# 儲存的網路端點數量1 * 20k = 20k200 * 100 = 20k
每個資源的大小20k * 常數 = ~2.0 MB100 * 常數 = ~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

關於端點切片的更多資訊

EndpointSlices 是 Kubernetes 1.16 中的 Alpha 版功能,預設情況下未啟用。 Endpoints API 將繼續預設啟用,但我們正在努力將最大的 Endpoints 消費者遷移到新的 EndpointSlice API。 值得注意的是,Kubernetes 1.16 中的 kube-proxy 包含對 EndpointSlices 的 Alpha 版支援。

官方 Kubernetes 文件包含有關 EndpointSlices 的更多資訊,以及如何在您的叢集中啟用它們。 還有一個 很棒的 KubeCon 演講,其中提供了有關開發此 API 的最初理由的更多背景資訊。

值得注意的功能更新

可用性

Kubernetes 1.16 版本已於 GitHub 開放下載。若要開始使用 Kubernetes,請參考這些互動式教學。您也可以使用 kubeadm 輕鬆安裝 1.16 版本。

發布團隊

本次發布歸功於數百位貢獻技術和非技術內容的個人努力。特別感謝由 Microsoft 首席專案經理 Lachlan Evenson 領導的發布團隊。發布團隊的 32 位成員協調了發布的許多方面,從文件編寫到測試、驗證和功能完整性。

隨著 Kubernetes 社群的成長,我們的發布流程展現了開源軟體開發中令人驚嘆的協作。Kubernetes 持續快速獲得新使用者。這種成長創造了正向回饋循環,更多貢獻者提交程式碼,創造了更蓬勃發展的生態系統。Kubernetes 至今已累積超過 32,000 位個人貢獻者,以及超過 66,000 人的活躍社群。

發布吉祥物

Kubernetes 1.16 發布徽章的靈感大致來自阿波羅 16 號任務徽章。它代表發布團隊和社群的辛勤工作,並頌揚我們在整個發布週期中作為團隊共同經歷的挑戰和歡樂時光。非常感謝 Microsoft 的 Ronan Flynn-Curran 創作了這件宏偉的作品。

Kubernetes 1.16 Release Mascot

Kubernetes 更新

專案速度

CNCF 持續精進 DevStats,這是一個雄心勃勃的專案,旨在視覺化專案中眾多的貢獻。K8s DevStats 展示了主要公司貢獻者的貢獻細目,以及一套令人印象深刻的預先設定報告,內容涵蓋從個人貢獻者到提取請求生命週期時間的所有內容。去年,1,147 家不同的公司和超過 3,149 位個人 每月為 Kubernetes 做出貢獻。查看 DevStats 以了解更多關於 Kubernetes 專案和社群的整體速度。

生態系統

KubeCon + CloudNativeCon

雲端原生運算基金會的旗艦會議將於 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,與社群一同聚會四天,進一步推動雲端原生運算的教育和發展。立即註冊

網路研討會

加入 Kubernetes 1.16 發布團隊成員於 2019 年 10 月 22 日舉辦的網路研討會,以了解本次發布的主要功能。在此註冊

參與其中

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