Kubernetes 1.26 正式發(fā)布爵卒，變化重大，所有更改都在這里了撵彻！

Kubernetes 1.26 已經(jīng)正式發(fā)布钓株，滿載新奇实牡！

此版本帶來了 37 項增強功能，與 Kubernetes 1.25 中的 40 項 和 Kubernetes 1.24 中的 46 項相當轴合。在這 37 項增強功能中创坞，11 項正在升級為穩(wěn)定版，10 項是不斷改進的現(xiàn)有功能受葛，16 項是全新的题涨，1 項是已棄用的功能。

此版本中有兩個突出的新功能总滩，它們有可能改變用戶與 Kubernetes 交互的方式：能夠使用來自其他命名空間的快照來配置卷纲堵。

還有一些針對高性能工作負載的新功能，例如科學研究或機器學習：更好地運行您的工作負載的物理 CPU 內(nèi)核闰渔。

此外席函，其他功能將使集群管理員的工作更輕松，例如對 OpenAPIv3 的支持冈涧。

現(xiàn)在讓我們開始了解 Kubernetes 1.26 中的新功能茂附。

Kubernetes 1.26 推薦功能

這些是我們在此版本中最令人興奮的功能 (ymmv)：

從跨命名空間快照配置卷

VolumeSnapshot 功能允許 Kubernetes 用戶從卷快照中配置卷，為用戶和應用程序帶來巨大好處督弓，例如使數(shù)據(jù)庫管理員能夠在任何關鍵操作之前對數(shù)據(jù)庫進行快照营曼，或者能夠開發(fā)和實施備份解決方案。

從 Kubernetes 1.26 開始愚隧，作為 Alpha 功能溶推，用戶將能夠跨命名空間從VolumeSnapshot創(chuàng)建PersistentVolumeClaim，打破了將兩個對象放在同一命名空間的初始限制奸攻。

此增強功能旨在消除阻止用戶和應用程序執(zhí)行基本任務的限制，例如當應用程序和服務位于不同命名空間時保存數(shù)據(jù)庫檢查點虱痕。

CEL 用于準入控制

來自 Kubernetes 1.25 的驗證表達式語言的實際實現(xiàn)睹耐！

通過將準入控制器的規(guī)則定義為 Kubernetes 對象，我們可以開始忘記管理 webhook部翘，從而簡化集群的設置硝训。不僅如此，現(xiàn)在實施 Kubernetes 安全性也更容易一些新思。

這些用戶友好的改進是保持 Kubernetes 采用率增長的關鍵窖梁。

Kubernetes 組件運行狀況 SLI

從 Kubernetes 1.26 開始，您可以為 Kubernetes 組件二進制文件配置服務級別指標 (SLI) 指標夹囚。啟用它們后纵刘，Kubernetes 將在/metrics/slis端點中公開 SLI 指標。因此您將不需要 Prometheus exporter荸哟。這可以將 Kubernetes 監(jiān)控提升到另一個級別假哎，從而更容易創(chuàng)建健康儀表板和配置 PromQL 警報以確保集群的穩(wěn)定性瞬捕。

cAdvisor-less, CRI-full 容器和 Pod 統(tǒng)計

目前，要從容器收集指標舵抹，例如消耗的 CPU 或內(nèi)存雷绢，Kubernetes 依賴于 cAdvisor沽讹。此功能提供了一種替代方案，豐富了 CRI API 以提供來自容器的所有指標，從而提供更大的靈活性和更高的準確性自赔。畢竟，最了解容器行為的是容器運行時驶拱。

此功能代表著在從 Kubernetes 代碼中刪除 cAdvisor 的路線圖上又邁出了一步伦糯。然而，在此過渡期間陶缺，cAdvisor 將被修改為不生成添加到 CRI API 的指標钾挟，避免具有可能不同和不連貫值的重復指標。

動態(tài)資源分配

這個 Kubernetes 版本引入了一個新的 Alpha 功能饱岸，它將為高級硬件提供擴展的資源管理掺出。它帶有一個用戶友好的 API 來描述資源請求。隨著處理不同硬件組件（如 GPU 或 FPGA）的需求不斷增加苫费，以及設置初始化和清理的需要汤锨，這一新功能將加速 Kubernetes 在科學研究或邊緣計算等領域的采用。

改進了拓撲管理器中的多 numa 對齊

這是另一個針對高性能工作負載的功能百框，例如那些涉及科學計算的功能闲礼。我們看到自 Kubernetes 1.22 和 1.23 以來新的 CPU 管理器正在形成，使開發(fā)人員能夠將他們的工作負載保持在靠近數(shù)據(jù)存儲在內(nèi)存中的位置铐维，從而提高性能柬泽。Kubernetes 1.26 更進了一步，為進一步定制此功能打開了大門嫁蛇。畢竟锨并，并非所有工作負載和 CPU 架構都是相同的。

事實上睬棚，Kubernetes 上的 HPC 的未來看起來很有希望第煮。

允許 StatefulSet 控制開始副本序號

Kubernetes 中的 StatefulSets 通常是關鍵的后端服務，例如集群數(shù)據(jù)庫或消息隊列抑党。

這種增強包警，看似微不足道的編號變化，允許更大的靈活性底靠，并支持滾動跨命名空間甚至 StatefulSet 副本的跨集群遷移的新技術害晦，而無需任何停機時間。

雖然這個過程可能看起來有點笨重暑中，涉及到對 PodDisruptionBudgets 的仔細定義和相對于遷移副本的資源移動篱瞎，但我們可以肯定有想象和實施空間(或現(xiàn)有的 operators 增強)可以自動化這些操作以實現(xiàn)無縫遷移苟呐，與目前可行的冷遷移策略(關機-備份-恢復)形成鮮明對比。

獲取自我用戶屬性的 Auth API

alpha 版的這項新功能將簡化集群管理員的工作俐筋，尤其是當他們管理多個集群時牵素。它還將協(xié)助復雜的身份驗證流程，因為它允許用戶在集群內(nèi)查詢他們的用戶信息或權限澄者。

此外笆呆，這還包括是否使用代理( Kubernetes API server 在應用了所有身份驗證機制后填寫 userInfo )或模擬(您將獲得被模擬用戶的詳細信息和屬性) ，因此您將以一種非常簡單的方式獲得用戶信息粱挡。

聚合發(fā)現(xiàn) Aggregated Discovery

這對于用戶來說是一個很小的改變赠幕，但是在清潔 Kubernetes 內(nèi)部結構和提高其性能方面又向前邁進了一步。通過聚合 API 調(diào)用(或者至少在發(fā)現(xiàn)部分)來減少 API 調(diào)用的數(shù)量是解決日益嚴重的問題的一個很好的辦法询筏。希望這將為集群管理員提供一個小小的突破榕堰。

棄用

Kubernetes 1.26 中刪除了一些 beta API 和功能，包括：

不再提供的棄用 API 版本嫌套，您應該使用更新的版本：

• CRI v1alpha2已經(jīng)棄用逆屡，使用v1（不支持 containerd 1.5 及更早版本）。
• flowcontrol.apiserver.k8s.io/v1beta1已經(jīng)棄用踱讨，使用v1beta2魏蔗。
• autoscaling/v2beta2已經(jīng)棄用，使用v2痹筛。

已棄用莺治。在下一個版本發(fā)布之前請實施替代方案：

• 樹內(nèi) GlusterFS 驅動程序。
• kubectl --prune-whitelist帚稠，用--prune-allowlist代替谣旁。
• kube-apiserver --master-service-namespace.
• 若干個未使用的選項 kubectl run：--cascade, --filename, --force, --grace-period, --kustomize, --recursive, --timeout, --wait。
• CLI flag pod-eviction-timeout滋早。
• apiserver_request_slo_duration_seconds指標榄审，使用apiserver_request_sli_duration_seconds代替.

已刪除。在升級之前請實施替代方案：

• Azure 和 Google Cloud 的舊版身份驗證已棄用馆衔。
• userspace proxy 模式。
• 動態(tài) kubelet 配置怨绣。
• 若干個與日志相關的命令行參數(shù)角溃。
• in-tree OpenStack（cinder卷類型），使用CSI 驅動程序代替篮撑。

其他更改： 應該調(diào)整配置

• Pod 安全準入：pod-security warn level 現(xiàn)在將默認為enforcelevel减细。
• kubelet：啟用 cpuCFSQuotaperiod 標志的默認 cpuCFSQuotaperiod 值現(xiàn)在是 100μs，而不是 100ms赢笨。
• kubelet：--container-runtime-endpoint標志不能再為空未蝌。
• kube-apiserver：gzip 壓縮從級別 4 切換到級別 1驮吱。
• 指標：preemption_victims從LinearBuckets更改為ExponentialBuckets。
• 指標：etcd_db_total_size_in_bytes重命名為apiserver_storage_db_total_size_in_bytes.
• 指標：kubelet_kubelet_credential_provider_plugin_duration已更名為kubelet_credential_provider_plugin_duration.
• 指標：kubelet_kubelet_credential_provider_plugin_errors已更名為kubelet_credential_provider_plugin_errors.
• 從各種容器映像中刪除了 Windows Server 版本 20H2 風格萧吠。
• e2e.test 二進制文件不再發(fā)出 JSON 結構來記錄進度左冬。

您可以在Kubernetes 1.26 發(fā)行說明中查看完整的更改列表。此外纸型，我們推薦Kubernetes Removals and Deprecations In 1.26文章拇砰，并保留已棄用的 API 遷移指南以備將來使用。

#281動態(tài) Kubelet 配置

功能組：節(jié)點

自 Kubernetes 1.11 以來處于測試階段后狰腌，Kubernetes 團隊決定棄用DynamicKubeletConfig而不是繼續(xù)開發(fā)除破。

此功能在 1.21 中被標記為棄用，然后在 1.24 中從 Kubelet 中刪除∏砬唬現(xiàn)在在 1.26 中瑰枫，它已經(jīng)完全從 Kubernetes中移除。

Kubernetes 1.26 API

#3352聚合發(fā)現(xiàn)

階段： Net new to Alpha
特性組： api-machinery
特性門： AggregatedDiscoveryEndpoint
默認值： false

每個 Kubernetes 客戶端（例如：kubectl）需要發(fā)現(xiàn) kubernetes-apiserver丹莲，為此光坝，他們需要針對每個 API 和版本發(fā)出請求，這會導致請求風暴圾笨。

此增強功能旨在將所有這些調(diào)用減少到兩個教馆。

客戶端可以將as=APIGroupDiscoveryList包含到其請求的Accept字段中，以請求/api和/apis端點擂达。然后土铺，服務器將返回一個包含所有可用 API 及其版本的聚合文檔 (APIGroupDiscoveryList)。

#3488 CEL 用于準入控制

階段： Net new to Alpha
功能組： api-machinery
特征門： ValidatingAdmissionPolicy
默認值： false

從 Kubernetes 1.25 引入的 CRD 驗證表達式語言板鬓，此增強功能提供了一種新的準入控制器類型 ( ValidatingAdmissionPolicy )悲敷，允許在不依賴 webhook 的情況下實現(xiàn)一些驗證。

這些新政策可以定義如下：

 apiVersion: admissionregistration.k8s.io/v1alpha1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: "demo-policy.example.com"
 Spec:
   failurePolicy: Fail
   matchConstraints:
     resourceRules:
     - apiGroups:   ["apps"]
       apiVersions: ["v1"]
       operations:  ["CREATE", "UPDATE"]
       resources:   ["deployments"]
   validations:
     - expression: "object.spec.replicas <= 5"

此策略將拒絕具有5或更少副本的 deployments 請求俭令。

在文檔中發(fā)現(xiàn)此功能的全部功能后德。

#1965 kube-apiserver 身份

階段： Graduating to Beta
特性組： api-machinery
特性門： APIServerIdentity
默認值： true

為了更好地控制哪些 kube-apiservers 在高可用性集群中處于活動狀態(tài)，已經(jīng)實施了新的租用/心跳系統(tǒng)抄腔。

Kubernetes 1.26 中的應用程序

#3017 PodDisruptionBudget 的 PodHealthyPolicy

階段： Net new to Alpha
功能組： apps
功能門： PDBUnhealthyPodEvictionPolicy
默認值： false

PodDisruptionBudget 允許您與集群管理員溝通一些最低要求瓢湃，以簡化維護任務，例如“不要銷毀其中一個以上”或“至少讓其中兩個保持活動狀態(tài)”赫蛇。

但是绵患，這僅考慮 pod 是否正在運行，而不考慮它們是否健康悟耘。您的 pod 可能正在運行但未就緒落蝙，并且 PodDisruptionBudget 可能會阻止其被驅逐。

此增強功能使用 status.currentHealthy``status.desiredHealthy和spec.unhealthyPodEvictionPolicy 字段擴展了這些預算定義，以幫助您定義如何管理不健康的 pod筏勒。

$ kubectl get poddisruptionbudgets example-pod
apiVersion: policy/v1
kind: PodDisruptionBudget
[...]
status:
  currentHealthy: 3
  desiredHealthy: 2
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1
  unhealthyPodEvictionPolicy: IfHealthyBudget

#3335允許 StatefulSet 控制開始副本序號

階段： Net new to Alpha
功能組： apps
功能門： StatefulSetStartOrdinal
默認值： false

Kubernetes 中的 StatefulSets 目前使用序號為它們的 pod 編號移迫，第一個副本是0，最后一個是spec.replicas管行。

此增強功能向 StatefulSet 清單規(guī)范添加了一個具有單個字段的新結構 spec.ordinals.start厨埋，它允許定義由 StatefulSet 控制的副本的起始編號。

這很有用病瞳，例如揽咕，在 StatefulSet 的跨命名空間或跨集群遷移中，巧妙地使用 PodDistruptionBudgets（和多集群服務）可以允許副本的受控滾動遷移套菜，避免任何停機時間亲善。

#3329 Jobs 的可重試和不可重試 Pod 失敗

階段： Graduating to Beta
功能組： apps
功能門： JobPodFailurePolicy， 默認值： true
功能門: ： PodDisruptionsCondition逗柴，默認值： true

此增強功能允許我們在Jobs的規(guī)范上配置.spec.podFailurePolicy蛹头，確定在失敗的情況下是否應重試 Job 的規(guī)范。這樣戏溺，Kubernetes 可以提前終止作業(yè)渣蜗，避免在基礎設施故障或應用程序錯誤的情況下增加退避時間。

#2307 無需遺留 Pod 來跟蹤 Job

階段： Graduating to Stable
功能組： apps
功能門： JobTrackingWithFinalizers
默認值： true

通過此增強功能旷祸，Jobs 將能夠更早地刪除已完成的 pod耕拷，從而釋放集群中的資源。

Kubernetes 1.26 授權

#3325 獲取用戶屬性的 Auth API

階段： Net new to Alpha
特性組： auth
特性門： APISelfSubjectAttributesReview
默認值： false

當在 Kubernetes 集群中使用復雜的身份驗證流托享，并且在應用了所有身份驗證機制之后希望了解所有 userInfo 時骚烧，這個新特性非常有用。

執(zhí)行kubectl alpha auth whoami將產(chǎn)生以下輸出：

apiVersion: authentication.k8s.io/v1alpha1
kind: SelfSubjectReview
status:
  userInfo:
    username: jane.doe
    uid: b79dbf30-0c6a-11ed-861d-0242ac120002
    groups:
    - students
    - teachers
    - system:authenticated
    extra:
      skills:
      - reading
      - learning
      subjects:
      - math
      - sports

總之闰围，一旦在集群中進行了身份驗證赃绊，我們現(xiàn)在可以執(zhí)行典型的 /me 操作來了解自己的權限。

#2799 減少基于秘密的服務帳戶令牌

階段： Graduating to Beta
特性組： auth
特性門： LegacyServiceAccountTokenNoAutoGeneration
默認值： true

API 憑據(jù)現(xiàn)在通過TokenRequest API獲得羡榴，自 Kubernetes 1.22 以來穩(wěn)定碧查，并使用projected卷安裝到 Pod 中。當它們關聯(lián)的 Pod 被刪除時校仑，它們將自動失效忠售。

Kubernetes 1.26 中的網(wǎng)絡

#3453最小化 iptables-restore 輸入大小

階段： Net new to Alpha
特性組：網(wǎng)絡
特性門： MinimizeIPTablesRestore
默認值： false

此增強功能旨在提高kube-proxy. 它將通過僅發(fā)送調(diào)用時已更改的規(guī)則iptables-restore而不是整套規(guī)則來實現(xiàn)。

#1669 代理終止端點

階段： Graduating to Beta
特性組： network
特性門： ProxyTerminatingEndpoints
默認值： true

此增強功能通過將所有外部流量發(fā)送到就緒和未就緒的終止端點（首選就緒端點）來防止?jié)L動更新期間的流量丟棄迄沫。

#2595擴展的 DNS 配置

階段： Graduating to Beta
特性組： network
特性門： ExpandedDNSConfig
默認值： true

通過此增強功能稻扬，Kubernetes 允許在搜索路徑中使用最多 32 個 DNS，并增加搜索路徑的字符數(shù)（最多 2048 個）邢滑，以跟上最新的 DNS 解析器腐螟。

#1435 在 type=LoadBalancer 的服務中支持混合協(xié)議

階段： Graduating to Stable
特性組： network
特性門： MixedProtocolLBService
默認值： true

此增強功能允許 LoadBalancer 服務在同一端口為不同協(xié)議（UDP、TCP）提供服務困后。例如乐纸，在同一端口上為 DNS 或 SIP 服務器提供 UDP 和 TCP 請求。

#2086服務內(nèi)部流量策略

階段： Graduating to Stable
特性組： network
特性門： ServiceInternalTrafficPolicy
默認值： true

您現(xiàn)在在Service對象上設置spec.trafficPolicy字段以優(yōu)化集群流量：

• 使用Cluster摇予，路由將照常運行汽绢。
• 當設置為Topology時，它將使用拓撲感知路由侧戴。
• 使用PreferLocal宁昭，它將流量重定向到同一節(jié)點上的服務。
• 使用Local酗宋，它只會將流量發(fā)送到同一節(jié)點上的服務积仗。

#3070為動態(tài)和靜態(tài) IP 分配保留服務 IP 范圍

階段： Graduating to Stable
特性組： network
特性門： ServiceIPStaticSubrange
默認值： true

此--service-cluster-ip-range標志更新將降低使用靜態(tài)和動態(tài) IP 分配的服務之間發(fā)生 IP 沖突的風險，同時保持向后兼容性蜕猫。

Kubernetes 1.26 節(jié)點

#2371 cAdvisor-less, CRI-full 和 Pod 統(tǒng)計

階段： Alpha
功能組的重大變化：節(jié)點
功能門： PodAndContainerStatsFromCRI
Default value: false

此增強功能總結了從容器運行時接口 (CRI)檢索有關正在運行的容器和 pod 的所有統(tǒng)計信息的工作寂曹，從 cAdvisor 中刪除了依賴項。

從 1.26 開始回右，指標/metrics/cadvisor由 CRI 而不是 cAdvisor 收集隆圆。

#3063動態(tài)資源分配

階段： Net new to Alpha
特性組： node
特性門： DynamicResourceAllocation
默認值： false

傳統(tǒng)上，Kubernetes 調(diào)度程序只能考慮 CPU 和內(nèi)存限制和請求翔烁。后來渺氧，調(diào)度程序得到擴展，也考慮了存儲和其他資源蹬屹。然而侣背，這在許多情況下是有限制的。

例如哩治，如果設備需要初始化和清理秃踩，就像 FPGA 一樣；或者业筏，如果您想限制對資源（如共享 GPU）的訪問怎么辦憔杨？

這個新的 API 涵蓋了那些資源分配和動態(tài)檢測的場景，使用了新的ResourceClaimTemplate和ResourceClass 對象蒜胖，以及 Pods 內(nèi)部的resourceClaims 新變量消别。

apiVersion: v1
 kind: Pod
# [...]
 spec:
   resourceClaims:
   - name: resource0
     source:
       resourceClaimTemplateName: resource-claim-template
   - name: resource1
     source:
       resourceClaimTemplateName: resource-claim-template
# [...]

調(diào)度器可以跟蹤這些資源聲明，并且只在那些具有足夠可用資源的節(jié)點中調(diào)度 Pod台谢。

#3386 Kubelet evented PLEG 以獲得更好的性能

階段： Net new to Alpha
特性組： node
特性門： EventedPLEG
默認值： false

此增強功能的目的是減少kubelet跟蹤所有 pod 狀態(tài)時的 CPU 使用率寻狂。

它將部分減少kubelet執(zhí)行的定期輪詢，而不是盡可能依賴來自容器運行時接口 (CRI) 的通知朋沮。

如果你對實現(xiàn)細節(jié)感興趣蛇券，你可能想看看 KEP。

#3545改進了拓撲管理器中的多 NUMA 對齊

階段： Net new to Alpha
功能組：節(jié)點
功能門： TopologyManagerPolicyOptions 默認值： false
功能門： TopologyManagerPolicyBetaOptions，默認值：false
功能門: TopologyManagerPolicyAlphaOptions纠亚，默認值： false

這是TopologyManager的一項改進塘慕，可以更好地處理非統(tǒng)一內(nèi)存訪問 ( NUMA ) 節(jié)點。對于某些高性能工作負載蒂胞，控制它們在哪些物理 CPU 內(nèi)核中運行非常重要图呢。如果避免同一芯片的高速緩存之間或套接字之間的內(nèi)存跳轉，則可以顯著提高性能骗随。

kubelet的一個新標志topology-manager-policy-options將允許您傳遞選項并修改拓撲管理器的行為蛤织。

目前，只有一個 alpha 選項可用：

• 傳遞時prefer-closest-numa-nodes=true鸿染，拓撲管理器將在單個 NUMA 節(jié)點或盡可能少的 NUMA 節(jié)點上對齊資源指蚜。

由于將來可能會添加新選項，因此添加了幾個功能門控涨椒，因此您可以選擇只關注穩(wěn)定的功能門：

• TopologyManagerPolicyOptions: 將啟用topology-manager-policy-options標志和穩(wěn)定選項姚炕。
• TopologyManagerPolicyBetaOptions: 還將啟用 beta 選項。
• TopologyManagerPolicyAlphaOptions: 還將啟用 alpha 選項丢烘。

#2133 Kubelet 憑證提供程序

階段： Graduating to Stable
特性組： node
特性門： KubeletCredentialProviders
默認值： true

此增強功能用外部和可插入的新機制取代了樹內(nèi)容器鏡像注冊表憑證提供程序柱宦。

#3570CPUManager 畢業(yè)到 GA

階段： Graduating to Stable
特性組： node
特性門： CPUManager
默認值： true

CPUManager 是負責將 pod 容器分配給本地節(jié)點上的 CPU 集的 Kubelet 組件。

它在 Kubernetes 1.8 中引入播瞳，并在 1.10 版本中升級為 beta 版掸刊。對于 1.26，核心 CPUManager 被認為是穩(wěn)定的赢乓，同時實驗繼續(xù)對其策略進行額外的工作忧侧。

#3573DeviceManager 畢業(yè)到 GA

階段： Graduating to Stable
特性組： node
特性門： DevicePlugins
默認值： true

Kubelet 中的 DeviceManager 是管理與不同設備插件交互的組件。

Device Plugin 框架最初在 Kubernetes 1.8 中引入牌芋，并在 1.10 版中進入 beta 階段蚓炬，得到廣泛采用，最終在 1.26 中進入 GA躺屁。

該框架允許在不修改核心 Kubernetes 組件的情況下使用外部設備肯夏。例如， NVIDIA GPU犀暑、AMD GPUS驯击、SR-IOV NIC

Kubernetes 1.26 中的調(diào)度

#3521 Pod 調(diào)度就緒

階段： Net new to Alpha
功能組： scheduling
特性門: PodSchedulingReadiness
默認值： false

此增強旨在通過讓 Pod 定義它們何時準備好實際調(diào)度來優(yōu)化調(diào)度。

并非所有待處理的 Pod都已準備好進行調(diào)度耐亏。有些會在某種miss-essential-resources狀態(tài)下停留一段時間徊都，這會導致調(diào)度程序進行額外的工作。

Pod 的新字段.spec.schedulingGates允許識別它們何時準備好進行調(diào)度：

apiVersion: v1
 kind: Pod
[...]
 spec:
   schedulingGates:
   - name: foo
   - name: bar
[...]

當存在任何調(diào)度門時广辰，Pod 將不會被調(diào)度暇矫。

您可以使用以下方式檢查狀態(tài)：

$ kubectl get pod test-pod
 NAME       READY   STATUS            RESTARTS   AGE
 test-pod   0/1     SchedulingGated   0          7s

#3094 在計算計算 PodTopologySpread 偏斜時考慮污點/容忍度

階段： Graduating to Beta
Feature group： scheduling
Feature gate： NodeInclusionPolicyInPodTopologySpread
默認值： true

topologySpreadConstraints字段以及maxSkew允許您跨節(jié)點分散工作負載主之。一個新的NodeInclusionPolicies字段允許在計算此 pod 拓撲分布偏差時考慮NodeAffinity和NodeTaint。

Kubernetes 1.26 存儲

#3294從跨命名空間快照配置卷

階段： Net new to Alpha
特性組： storage
特性門： CrossNamespaceVolumeDataSource
默認值： false

在 Kubernetes 1.26 之前李根，由于 VolumeSnapshot 的特性杀餐，用戶可以從快照中提供卷。雖然這是一個偉大的和超級有用的功能朱巨。它有一些局限性，比如無法將 PersisentVolumeClaim 綁定到來自其他名稱空間的 VolumeSnapshot枉长。

這種增強打破了這個限制冀续，允許 Kubernetes 用戶從跨名稱空間的快照提供卷。

如果要使用跨名稱空間的 VolumeSnapshot 特性必峰，首先必須創(chuàng)建 ReferenceGrant 對象洪唐，然后創(chuàng)建一個到 VolumeSnapshot 的 PersisentVolumeClaim 綁定。在這里吼蚁，您將找到一個簡單的例子來說明這兩個對象的學習目的凭需。

---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferenceGrant
metadata:
  name: test
  namespace: default
spec:
  from:
  - group: ""
    kind: PersistentVolumeClaim
    namespace: nstest1
  to:
  - group: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: testsnapshot
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: testvolumeclaim
  namespace: nstest1
spec:
  storageClassName: mystorageclass
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  dataSourceRef2:
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: testsnapshot
    namespace: default
  volumeMode: Filesystem

#2268非正常節(jié)點關閉

階段： Graduating to Beta
特性組： storage
特性門： NodeOutOfServiceVolumeDetach
默認值： true

此增強解決了未正確檢測到的節(jié)點關閉情況，其中屬于StatefulSet的 pod 將停留在關閉節(jié)點上的終止狀態(tài)肝匆，并且無法移動到新的運行節(jié)點粒蜈。

在這種情況下，pod 將被強制刪除蘑拯，觸發(fā)VolumeAttachments的刪除兜蠕，新的 pods 將在不同的運行節(jié)點上創(chuàng)建挣轨，以便應用程序可以繼續(xù)運行。

#3333追溯默認 StorageClass 分配

階段： Graduating to Beta
特性組： storage
特性門： RetroactiveDefaultStorageClass
默認值： false

這種增強有助于管理集群管理員更改默認存儲類時的情況度硝。所有在更改發(fā)生時創(chuàng)建的沒有 StorageClass 的 PVC 將追溯設置為新的默認 StorageClass。

#1491 vSphere 從樹內(nèi)遷移到 CSI 驅動程序

階段： Graduating to Stable
特性組： storage
特性門： CSIMigrationvSphere
默認值： false

vSphere 的 CSI 驅動程序已經(jīng)穩(wěn)定了一段時間∈倜幔現(xiàn)在蕊程，所有插件操作vspherevolume現(xiàn)在都重定向到樹外的 csi.vsphere.vmware.com 驅動程序。

此增強功能是#625 In-tree 存儲插件到 CSI 驅動程序遷移工作的一部分驼唱。

#1885 Azure 文件從樹內(nèi)到 CSI 驅動程序遷移

階段： Graduating to Stable
特性組： storage
特性門： InTreePluginAzureDiskUnregister
默認值： true

此增強功能總結了將 Azure 文件代碼移出主要 Kubernetes 二進制文件（樹外）的工作藻茂。

#2317允許 Kubernetes 在掛載時將 pod 的 fsgroup 提供給 CSI 驅動程序

階段：畢業(yè)到穩(wěn)定
功能組：存儲
功能門： DelegateFSGroupToCSIDriver
Default value: false

這個增強建議將 pods 的 fsgroup 作為一個顯式字段提供給 CSI 驅動程序，因此 CSI 驅動程序可以在掛載時本地應用這個組玫恳。

Kubernetes 1.26 中的其他增強功能

#3466 Kubernetes 組件運行狀況 SLI

階段： Net new to Alpha
特性組： instrumentation
特性門： ComponentSLIs
默認值： false

查詢 Kubernetes 組件的健康數(shù)據(jù)沒有標準格式捌治。

從 Kubernetes 1.26 開始，一個新的 endpoint：/metrics/slis將對每個組件可用纽窟，以 Prometheus 格式公開其服務水平指標 (SLI) 指標肖油。

對于每個組件，將公開兩個指標：

• 一個gauge臂港，代表健康檢查的當前狀態(tài)森枪。
• 一個計數(shù)器视搏，記錄每個健康檢查狀態(tài)觀察到的累積計數(shù)。

使用此信息县袱，您可以檢查 Kubernetes 內(nèi)部的超時狀態(tài)浑娜，例如：

kubernetes_healthcheck{name="etcd",type="readyz"}

并在出現(xiàn)問題時創(chuàng)建警報，例如：

kubernetes_healthchecks_total{name="etcd",status="error",type="readyz"} > 0

#3498擴展指標穩(wěn)定性

階段： Net new to Alpha
特性組： instrumentation
特性門： N/A

Kubernetes 中的指標分為alpha或stable式散。這些stable保證會得到維護筋遭，為您提供信息來準備您的儀表板，這樣它們就不會在您升級集群時意外中斷暴拄。

在 Kubernetes 1.26 中漓滔，新增了兩個類：

• beta：用于與測試版功能相關的指標。它們可能會改變或消失乖篷，但它們處于比 alpha 更高級的開發(fā)狀態(tài)响驴。
• internal：您不必擔心的內(nèi)部使用指標，要么是因為它們沒有為集群管理員提供有用的信息撕蔼，要么是因為它們可能會更改而不另行通知豁鲤。

您可以在文檔中查看可用指標的完整列表。

#3515 用于 kubectl 的 OpenAPI v3 說明

階段： Net new to Alpha
特性組： cli
環(huán)境變量： KUBECTL_EXPLAIN_OPENAPIV3
默認值： false

此增強功能允許kubectl explain從 OpenAPIv3 而不是 v2 收集數(shù)據(jù)鲸沮。

在 OpenAPIv3 中琳骡，一些數(shù)據(jù)可以用更好的方式表示，例如CustomResourceDefinition (CDR)讼溺。

還正在進行內(nèi)部工作以改進kubectl explain打印輸出的方式日熬。

#1440 kubectl 事件

階段：升級到 Beta
功能組： cli
功能門： N/A

一個新kubectl events命令可用，它將增強kubectl get events.

#3031簽署發(fā)布工件

階段：升級到 Beta
功能組：發(fā)布
功能門： N/A

此增強功能引入了一種統(tǒng)一的方法來簽署工件肾胯，以幫助避免供應鏈攻擊竖席。它依賴于sigstore項目工具，更具體地說cosign敬肚。雖然它沒有添加新功能毕荐，但它肯定有助于使我們的集群受到更多保護。

#3503 Windows pod 的主機網(wǎng)絡支持

階段： Net new to Alpha
功能組： windows
功能門： WindowsHostNetwork
默認值： false

Windows pod 中有一種奇怪的情況艳馒，您可以在其中為它們設置hostNetwork=true憎亚，但它不會改變?nèi)魏螙|西。沒有任何平臺障礙弄慰，只是缺少實現(xiàn)第美。

從 Kubernetes 1.26 開始，kubelet現(xiàn)在可以請求 Windows pod 使用主機的網(wǎng)絡命名空間陆爽，而不是創(chuàng)建新的 pod 網(wǎng)絡命名空間什往。

這將很方便地避免有大量服務的端口耗盡。

#1981支持 Windows 特權容器

階段：畢業(yè)到穩(wěn)定
功能組： windows
功能門： WindowsHostProcessContainers
默認值: true

此增強功能將 Linux 中可用的特權容器功能引入到了 Windows 主機慌闭。

特權容器可以訪問主機别威，就好像它們直接在主機上運行一樣躯舔。盡管不建議將它們用于大多數(shù)工作負載，但它們對于管理省古、安全和監(jiān)控目的非常有用粥庄。

出處

作者：sysdig
原文：https://sysdig.com/blog/kubernetes-1-26-whats-new/

說明

請關注 危 ? 工中號【進擊云原生】，更有 free 資源供您學習

本文由mdnice多平臺發(fā)布