今天，星期三， Kubernetes 的下一個版本 - 1.16。 根據我們部落格的傳統，這是我們談論新版本中最重大變化的十週年紀念日。
用於準備本資料的資訊取自 , 以及相關問題、拉取請求和 Kubernetes 增強提案 (KEP)。 那麼，我們走吧！...
節點數
K8s 叢集節點（Kubelet）方面出現了真正大量值得注意的創新（處於 alpha 版本狀態）。
首先，所謂的 «» （臨時容器），旨在簡化 pod 中的調試過程。 新機制可讓您啟動特殊容器，這些容器在現有 Pod 的命名空間中啟動並存活很短的時間。 它們的目的是與其他 Pod 和容器交互，以解決任何問題並進行調試。 為此功能實施了一個新命令 kubectl debug，本質上類似於 kubectl exec：僅代替在容器中運行進程（如 exec）它在 pod 中啟動一個容器。 例如，此指令會將新容器連接到 pod：
kubectl debug -c debug-shell --image=debian target-pod -- bash有關臨時容器（及其使用範例）的詳細資訊可以在 。 目前的實作（在 K8s 1.16 中）是 alpha 版本，轉移到 beta 版本的標準之一是「針對至少 2 個版本的 [Kubernetes] 測試 Ephemeral Containers API」。
NB：從本質上講，甚至從名稱上看，該功能類似於現有的插件 關於我們 。 預計隨著臨時容器的出現，單獨的外部插件的開發將停止。
另一項創新—— - 旨在提供 計算 pod 間接成本的機制，根據所使用的運行時的不同，可能會有很大差異。 舉個例子，作者 結果是 Kata 容器，需要運行來賓核心、kata 代理、init 系統等。 當開銷變得如此之大時，它就不能被忽視，這意味著需要有一種方法將其考慮到進一步的配額、規劃等。 為了實現它在 PodSpec 新增字段 Overhead *ResourceList （與中的數據比較 RuntimeClass，如果使用的話）。
另一個值得注意的創新是 節點拓撲管理器 （節點拓撲管理器），旨在統一微調 Kubernetes 中各個元件的硬體資源分配的方法。 這項措施是由各種現代系統（來自電信、機器學習、金融服務等領域）對高效能並行運算和最大限度地減少營運執行延遲的日益增長的需求所推動的，為此它們使用先進的CPU和硬體加速能力。 到目前為止，Kubernetes 中的此類最佳化已經透過不同的元件（CPU 管理器、裝置管理員、CNI）實現，現在它們將添加一個單一的內部接口，統一方法並簡化新的類似（所謂的拓撲）的連接。感知 - Kubelet 端的組件。 詳細資訊 - 在 .
拓樸管理器元件圖
下一個功能 - 在容器運作時檢查容器 ()。 如您所知，對於需要很長時間才能啟動的容器，很難獲得最新狀態：它們要么在真正開始運行之前被“殺死”，要么最終陷入很長一段時間的僵局。 新檢查（透過名為的功能門啟用 StartupProbeEnabled) 取消（或更確切地說，推遲）任何其他檢查的效果，直到 pod 完成運行為止。 因此，該功能最初被稱為 。 對於啟動時間較長的 Pod，您可以以相對較短的時間間隔進行輪詢狀態。
此外，對 RuntimeClass 的改進在測試版狀態中立即可用，增加了對「異質叢集」的支援。 C 現在，每個節點完全沒有必要支援每個 RuntimeClass：對於 pod，您可以選擇一個 RuntimeClass，而無需考慮叢集拓撲。 以前，為了實現這一目標（以便 Pod 最終位於支援其所需一切的節點上），有必要為 NodeSelector 和容忍分配適當的規則。 在 它討論了使用範例，當然還有實作細節。
Сеть
Kubernetes 1.16 中首次（alpha 版本）出現的兩個重要網路功能是：
- 雙網路堆疊 - IPv4/IPv6 - 及其在 Pod、節點、服務層面的相應「理解」。 它包括 Pod 之間、從 Pod 到外部服務的 IPv4 到 IPv4 和 IPv6 到 IPv6 互通性、參考實作（在 Bridge CNI、PTP CNI 和 Host-Local IPAM 插件內），以及與運行的 Kubernetes 叢集反向相容僅限IPv4 或IPv6。 實施細節見 .
在 pod 清單中顯示兩種類型（IPv4 和 IPv6）的 IP 位址的範例：
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - 端點的新 API - 。 它解決了現有 Endpoint API 的效能/可擴充性問題，這些問題影響控制平面中的各種元件（apiserver、etcd、endpoints-controller、kube-proxy）。 新的 API 將添加到 Discovery API 群組中，並且能夠為由數千個節點組成的叢集中每個服務上的數萬個後端端點提供服務。 為此，每個服務都映射到 N 個對象
EndpointSlice，每個端點預設不超過100個（該值是可配置的）。 EndpointSlice API 也將為其未來的發展提供機會：支援每個 pod 的多個 IP 位址、端點的新狀態（不僅ReadyиNotReady），端點的動態子集化。
上一版本提供的版本已達測試版 ，命名為 service.kubernetes.io/load-balancer-cleanup 並附加到每個服務的類型 LoadBalancer。 刪除此類服務時，它會阻止實際刪除資源，直到完成所有相關平衡器資源的「清理」。
API機械
真正的「穩定里程碑」是在 Kubernetes API 伺服器及其互動領域。 這很大程度上歸功於 轉入穩定狀態者，無需特殊介紹 （CRD），自 Kubernetes 1.7 遙遠的日子以來（現在是 2017 年 XNUMX 月！），它就處於 Beta 狀態。 相關功能也具有相同的穩定性：
- 同
/statusи/scale對於自訂資源； - CRD 版本，基於外部 webhook；
- （在 K8s 1.15 中）預設值 (預設) 和自動欄位移除 （修剪） 對於自訂資源；
- 使用 OpenAPI v3 架構建立和發佈用於在伺服器端驗證 CRD 資源的 OpenAPI 文件。
Kubernetes 管理員早已熟悉的另一個機制： - 也長期處於測試狀態（自 K8s 1.9 起），現已宣布穩定。
另外兩個功能已達到測試版： и .
alpha 版本中唯一重大的創新是 從 SelfLink — 表示指定物件並作為其一部分的特殊 URI ObjectMeta и ListMeta （即 Kubernetes 中任何物件的一部分）。 他們為什麼要放棄它？ 以簡單的方式激勵 因為缺乏真正的（壓倒性的）理由讓這個領域仍然存在。 更正式的原因是為了優化效能（透過刪除不必要的欄位）並簡化 generic-apiserver 的工作，該伺服器被迫以特殊方式處理此類欄位（這是在物件之前設定的唯一欄位）已連載）。 真正的過時（在測試版內） SelfLink 將在 Kubernetes 版本 1.20 和最終版本 1.21 中實作。
數據存儲
與先前的版本一樣，儲存區域的主要工作是在該區域中觀察到的 。 這裡的主要變化是：
- 第一次（alpha 版本） Windows 工作節點的 CSI 插件支援：目前的儲存運作方式也會取代 Kubernetes 核心中的樹內插件和 Microsoft 基於 Powershell 的 FlexVolume 外掛；
在 Kubernetes for Windows 中實作 CSI 插件的方案 - 機會 ，早在 K8s 1.12 就引入了，現已發展到 beta 版本；
- 透過使用 CSI 建立本地臨時磁碟區的能力，實現了類似的「升級」（從 alpha 到 beta）（).
在上一個版本的 Kubernetes 中引入 （使用現有的PVC作為 DataSource 建立新的 PVC）現在也已獲得測試狀態。
調度器
調度方面的兩個顯著變化（均為 alpha 版本）：
- - 機會 使用 Pod 而不是邏輯應用程式單元來「公平分配」負載 （如 Deployment 和 ReplicaSet）並調整此分佈（作為硬要求或軟條件，即優先權）。 該功能將擴展計劃中的 Pod 的現有分發功能，目前該功能受到選項的限制
PodAffinityиPodAntiAffinity，讓管理員在這方面有更精細的控制，這意味著更好的高可用性和優化的資源消耗。 詳細資訊 - 在 . - 使用 最佳適合政策 в RequestedToCapacityRatio 優先權函數 在 Pod 規劃期間，這將允許 申請 （「打包在容器中」）適用於基本資源（處理器、記憶體）和擴充資源（例如 GPU）。 有關更多詳細信息，請參閱 .
調度 Pod：在使用最佳適配策略之前（直接透過預設排程器）及其使用（透過排程器擴充功能）
另外， 能夠在主 Kubernetes 開發樹之外（樹外）創建自己的調度程序插件。
其他變化
另外，在 Kubernetes 1.16 版本中，您也可以注意到 倡議 可用指標的完整順序，或者更準確地說，根據 到 K8s 儀器。 他們很大程度上依賴相應的 。 由於各種原因出現了不一致（例如，一些指標只是在當前指令出現之前創建的），開發人員決定是時候將所有內容統一為單一標準，「與 Prometheus 生態系統的其他部分保持一致」。 目前該措施的實施處於 alpha 狀態，將在後續的 Kubernetes 版本中逐步提升至 beta (1.17) 和 stable (1.18)。
此外，還可以注意到以下變化：
- Windows支援開發 с 適用於該作業系統的 Kubeadm 實用程式（alpha 版本），
RunAsUserName對於 Windows 容器（alpha 版本）， 群組託管服務帳戶 (gMSA) 支援最高測試版本， 掛載/附加 vSphere 磁碟區。 - API回應中的資料壓縮機制。 以前，HTTP 過濾器用於這些目的，這施加了許多限制，導致預設無法啟用它。 「透明請求壓縮」現在有效：客戶端發送
Accept-Encoding: gzip在標頭中，如果其大小超過 128 KB，它們會收到 GZIP 壓縮的響應。 Go 用戶端自動支援壓縮（發送所需的標頭），因此它們會立即註意到流量的減少。 （其他語言可能需要稍作修改。） - 根據外部指標將 HPA 從零 Pod 擴展到零。 如果您基於物件/外部指標進行擴展，那麼當工作負載空閒時，您可以自動擴展到 0 個副本以節省資源。 對於工作執行緒請求 GPU 資源，並且不同類型的空閒工作執行緒的數量超過可用 GPU 數量的情況，此功能應該特別有用。
- 新客戶- — 用於對物件的「通用」存取。 它旨在輕鬆檢索元資料（即小節
metadata）從叢集資源中獲取並使用它們執行垃圾收集和配額操作。 - 建構 Kubernetes 沒有傳統（「內建」樹內）雲端提供者（alpha 版本）。
- 轉到 kubeadm 實用程序 實驗性（alpha 版本）能夠在操作期間應用自訂補丁
init,joinиupgrade。 了解有關如何使用該標誌的更多信息--experimental-kustomize，參見 . - apiserver 的新端點 - , - 允許您匯出有關其準備的資訊。 API 伺服器現在也有一個標誌
--maximum-startup-sequence-duration，允許您調節其重新啟動。 - 兩 Azure 的功能 宣布穩定：支持 （可用區）和 （RG）。 此外，Azure 還添加了：
- AAD 和 ADFS；
-
service.beta.kubernetes.io/azure-pip-name指定負載平衡器的公共IP； - 設置
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS 現在有 適用於 Windows 上的 EBS 和 EC2 API 呼叫
DescribeInstances. - Kubeadm 現已獨立 升級CoreDNS版本時的CoreDNS配置。
- 二進位檔案 等 在對應的Docker映像中 world-executable，它允許您運行此映像而無需 root 權限。 另外，etcd 遷移鏡像 etcd2 版本支援。
- В 改用 Distroless 作為基礎鏡像，提高了效能，並增加了新的雲端供應商（DigitalOcean、Magnum、Packet）。
- 使用/依賴軟體的更新：Go 1.12.9、etcd 3.3.15、CoreDNS 1.6.2。
聚苯乙烯
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com