刚刚 Kubernetes 1.25 正式发布，包括这些重大变化

就在刚刚 Kubernetes 1.25 正式发布，包括这些重大变化

此版本带来了 40 项增强功能，略少于Kubernetes 1.24中的 46 项。在这 40 项增强功能中，13 项正在升级到稳定版，10 项是对现有功能的不断改进，15 项是全新的，2 项是已弃用的功能。

此版本的亮点是 PodSecurityPolicies 被最终删除，取而代之的是 从毕业到稳定版的 PodSecurity admission。

有几个新的安全特性非常受欢迎，例如对 user namespaces 的支持、取证分析的检查点、安装卷时 SELinux 的改进、NodeExpansion Secret，以及对官方 CVE 提要的改进。

此外，其他功能将使集群管理员更轻松，例如：不可重试的 Pod 故障、KMS v2 改进、更清晰的 IPTables 链所有权、以及更好地处理 PVC 的 StorageClass 默认值。

最后，锦上添花的是这个版本的所有伟大的特性都达到了GA的状态。CSI的迁移已经进行了三年多，现在终于进入了最后阶段。此外，NetworkPolicies的端口范围, Ephemeral卷，并支持Cgroups v2。我们对这个版本非常兴奋!

有很多要谈的，现在让我们开始了解 Kubernetes 1.25 中的新功能。

Kubernetes 1.25 值得一提的功能

这些是在此版本中最令人兴奋的功能（因人而异）：

添加对 user namespaces 的支持

这种增强是 Kubernetes 在大约六年前首次提出的要求。它的目标是Kubernetes 1.5中达到alpha。实现这一特性的必要技术已经存在一段时间了。终于，它出现了，即使现在还处于alpha版本中。

Kubernetes 中的user namespaces有助于放松对工作负载的许多限制，允许使用在其他情况下被认为高度不安全的特性。希望这也将使攻击者更加困难。

取证容器 Checkpointing

容器检查点允许从特定容器创建快照，这样就可以对副本进行分析和调查。在不通知潜在攻击者的情况下，如果您设法在容器被摧毁之前捕获它，那么这将是一个很好的容器取证分析工具。

这不仅将永远改变Kubernetes的取证，而且将为Kubernetes提供安全和事件响应的每一个工具。

Jobs 的可重试和不可重试 Pod 故障

这是 Kubernetes Jobs 急需的改进。目前，如果 Job 失败并且它的 restartPolicy 设置为 OnFailure，Kubernetes 将尝试再次运行它，直到最大backoff限制。但是，当失败是由无法自行修复的应用程序错误引起时，这没有任何意义。

通过能够针对不同的故障原因设置策略，此增强功能将使 Kubernetes 更加高效，而不会浪费时间执行注定要失败的事情。它还将使 Jobs 对 pod 驱逐更可靠，这将大大减少管理员必须调查资源受限集群的失败 Jobs 的数量。

CSI 迁移~核心

这根本不是一个新特性，但存储SIG在这次迁移中值得称赞。他们不知疲倦地将CSI驱动程序从Kubernetes的核心转移了三年多，我们一直在跟踪他们的更新发布后发布。现在迁徙终于接近尾声。

从长远来看，这意味着Kubernetes代码的维护将更加容易，存储方面的功能也将更加酷炫。

KMS v2 改进

有了这个增强，管理加密密钥将更容易，需要的手动步骤也会更少。同时，使用该键的操作将会更快。这就是我们希望看到的安全改进、更好的安全性、改进的性能，并使管理员更轻松。

PodSecurityPolicy + Pod 安全控制

相信PodSecurityPolicy值得特别提一下，也是最后一提。它可能是Kubernetes生态系统中最被误解的组成部分之一，现在它终于消失了。

我们不应该忘记上游项目的变化，在这里是Kubernetes，也会影响其他 Kubernetes 发行版，比如Red Hat OpenShift。出于这个原因，他们发布了一个更新来解释他们如何使用新的 准入控制器 Pod 安全控制，这可能会给多个工程师带来一些头疼的问题。

弃用

API 和功能移除

Kubernetes 1.25 中删除了一些 beta API 和功能，包括：

  • 不再提供的已弃用API 版本（使用较新的版本）：

    • CronJob batch/v1beta1
    • EndpointSlice discovery.k8s.io/v1beta1
    • Event events.k8s.io/v1beta1
    • HorizontalPodAutoscaler autoscaling/v2beta1
    • PodDisruptionBudget policy/v1beta1
    • PodSecurityPolicy policy/v1beta1
    • RuntimeClass node.k8s.io/v1beta1

  • 其他 API 更改：

    • k8s.io/component-base已移至k8s.io/component-base/logs/api/v1（用于日志记录配置的 Go API）

  • 其他变化：

您可以在Kubernetes 1.25 发行说明中查看完整的更改列表。同时推荐Kubernetes 1.25 中的重大更改和删除文章，以及已弃用的 API 迁移指南。

#5 PodSecurityPolicy

阶段： 弃用
功能组： auth

Pod 安全策略 (PSP) 是一个出色的 Kubernetes 原生工具，用于限制部署可以执行的操作，例如将执行限制为用户列表，或访问网络或卷等资源。

PSP 在 Kubernetes 1.25 中被移除

此功能已被弃用，正在被 PodSecurity admission 取代。查看本指南以迁移到内置的 PodSecurity 准入插件。

#3446从树内驱动程序中弃用 GlusterFS 插件

阶段： 弃用
功能组： storage

Kubernetes 核心（树内）中包含的几个 CSI 插件正在迁移为单独的项目（树外）。随着此迁移的进行，树内对应物也被弃用。

除了 GlusterFS，还删除了对flocker、quobyte和storageos的支持。

Kubernetes 1.25 中的应用程序

#3329 Jobs 可重试和不可重试 Pod 故障

阶段： Net New to Alpha
功能组： apps
功能门： JobBackoffPolicy
默认值： false

目前，唯一可用于限制 Job 重试的选项是使用.spec.backoffLimit，此字段限制 Job 的最大重试次数，超过此 Job 将被视为失败。

然而，这并不能让我们辨别容器故障的原因。如果有已知的退出代码表示不可恢复的错误，最好将作业标记为失败，而不是浪费计算时间重试执行注定要失败的事情。另一方面，由于基础设施事件（例如 pod 抢占、内存压力驱逐或节点耗尽）导致容器失败，backoffLimit也是不可取的。

此增强功能允许我们.spec.backoffPolicy在Jobs的spec上配置一个，以确定在失败的情况下是否应重试 Job。通过根据故障原因采取不同的行为，Kubernetes 可以提前终止作业，避免在基础设施故障或应用程序错误的情况下增加backoff时间。

#1591 DaemonSets 应该支持 MaxSurge 以提高工作负载的可用性

阶段： Graduating 到 Stable
功能组： 应用程序
功能门： DaemonSetUpdateSurge
默认值： true

执行滚动更新时，该ec.strategy.rollingUpdate.maxSurge字段允许指定将创建多少新 Pod 来替换旧 Pod。

#2599将 minReadySeconds 添加到 Statefulsets

阶段： Graduating to Stable
功能组： 应用程序
功能门： StatefulSetMinReadySeconds
Default value: true

此增强功能为 StatefulSets 带来了可选的 minReadySeconds 字段，该字段已在 Deployments、DaemonSets、ReplicasSets 和 Replication Controllers 上可用。

如果声明，新创建的 Pod 将不会被认为是可用的，直到其容器保持就绪且在指定的秒数内没有崩溃。

#3140 CronJob 中的时区支持

阶段： Graduating 到 Beta
功能组： 应用程序
功能门： CronJobTimeZone
默认值： true

此功能支持延迟请求以支持 CronJob 资源中的时区。到目前为止，由 CronJobs 创建的作业都设置在同一时区，即 kube-controller-manager 进程所基于的时区。

Kubernetes 1.25 认证

#3299 KMS v2 改进

阶段： Net New to Alpha
功能组： auth
功能门： KMSv2
默认值： false

此新功能旨在提高密钥管理系统的性能和维护。

此增强解决的主要问题之一是必须为每个对象管理不同的 DEK（数据加密密钥）的低性能。当重新启动清空缓存的 kube-apiserver 进程后，执行LIST所有机密的操作时，这种情况尤其严重。解决方案是生成一个本地 KEK，它会延迟达到 KMS 速率限制。

目前，轮转密钥等任务涉及每个 kube-apiserver 实例的多次重启。这是必要的，因此每个服务器都可以使用新密钥进行加密和解密。此外，不加选择地重新加密集群中的所有机密是一项资源消耗任务，可能会使集群停止服务几秒钟，甚至依赖于旧密钥。此功能启用最新密钥的自动轮换。

此功能还将增加提高可观察性和健康检查操作的功能，目前这些操作是通过加密和解密资源来执行的，并且在云环境中成本很高。

这是一个非常令人兴奋的变化，它将帮助您减少对集群的保护。

从 KEP 了解更多信息。

#2579 PodSecurity admission

阶段： Graduating 到 稳定
特征组： auth
特征门： PodSecurity
默认值： true

现在默认启用新的PodSecurity 准入控制器，以替换 Kubernetes 1.21 中已弃用的 Pod 安全策略。

Kubernetes 1.25 中的网络

#2593 多个 ClusterCIDR

阶段： Graduating 到 Alpha
特征组： 网络
特征门： ClusterCIDRConfig
默认值： false

一旦创建了 Kubernetes 集群，扩展它就是一个真正的挑战。如果网络规模过大，我们会浪费很多 IP 地址。相反，对集群规模规划较小意味着在某个时间点，将不得不将其退役，并创建一个新的集群。

此增强功能将使集群管理员能够PodCIDR以更灵活的方式扩展 Kubernetes 集群，添加网络范围 PodCID 段。

  • 向集群添加更多 Pod IP：确实用完了 IP 段，并决定扩展集群。
  • 添加具有更高或更低能力的节点： 例如将未来节点中最大可分配的 Pod 数量增加一倍。
  • 提供不连续的范围：当网段没有均匀分布并且需要将其中的一些分组以部署新节点时很有用。

为此，创建新资源 ClusterCIDRConfig，允许通过节点分配器控制 CIDR 段。请记住，此配置不会影响或重新配置已配置的集群。目标是扩展 Kubernetes 中包含的 NodeIPAM 功能，而不是更改它。

#3178 清理 IPTables 链所有权

阶段： Graduating 到 Alpha
特征组： 网络
特征门： IPTablesOwnershipCleanup
默认值： false

始终建议进行清理，尤其是在您的代码中。kubelet历史上曾在IPTables中创建链来支持像dockershim或kube-proxy，随着 1.24 版本中 Dockershim 被移除，现在是时候清理它了。

kube-proxy则是另一回事。可以说，kube-proxy创建的链不属于它，而是属于kubelet，是时候把东西放在它们所属的地方了，停止kubelet 创造不必要的资源，让kube-proxy自己创建。

我们不会看到功能上的变化，但将管理一个更干净的集群。

#2079 NetworkPolicy 端口范围

阶段： Graduating 到 Stable
特征组： 网络
特征门： NetworkPolicyEndPort
默认值： true

此增强功能将允许您将 NetworkPolicy 中的所有端口定义为一个范围：

spec:
  egress:
  - ports:
    - protocol: TCP
      port: 32000
      endPort: 32768

#3070为动态和静态 IP 分配保留 Service IP 范围

阶段： Graduating 到 Beta
功能组： 网络
功能门： ServiceIPStaticSubrange
默认值： true

对--service-cluster-ip-range标志的更新，将降低使用静态和动态 IP 分配的服务之间发生 IP 冲突的风险，并在相同类型下保持向后兼容性。

Kubernetes 1.25 Nodes

#127添加对用户命名空间的支持

阶段： Graduating 到 Alpha
特征组： 节点
特征门： UserNamespacesSupport
默认值： false

一个期待已久的功能。有很多漏洞，由于授予 Pod 过多的权限，主机已被破坏。

Linux 内核支持用户命名空间已经有一段时间了。可以通过不同的容器运行时测试它们。将它们带入 Kubernetes 生态系统肯定会开启一系列新的可能性，比如让要求太高的容器相信它们在特权模式下运行；减少容器镜像的表面攻击对许多人来说似乎仍然是一个挑战。

你还记得上次有人请求CAP_SYS_ADMIN功能是什么时候吗？ 现在，由于这一增强，这些权限将在 Pod 中可用，但在主机中不可用。在容器内挂载 FUSE 文件系统或启动 VPN 不再是一件令人头疼的事情。

如果您还没有理解，让我们用更简单的语言说：容器内的进程将有两个身份（UID/GID）。一个在 Pod 内部，一个在外部，在主机上，它们有可能造成更大的危害。

如果想开始使用它，启用功能门 UserNamespacesSupport 并将 Pod 内的 spec.hostUsers 值设置为false（true或取消设置将使用主机用户，就像 Kubernetes 当前所做的那样）。但是，此功能尚不适合生产。

要了解有关此功能的更多信息，包含其他信息和因缺少此功能而受影响的 CVE 的详尽列表，请看 user-namespaces KEP

#2008取证容器 Checkpoint

阶段： Graduating 到 Alpha
特征组： 节点
特征门： ContainerCheckpointRestore
默认值： false

容器检查点可以拍摄正在运行的容器的快照。

可以将此快照传输到可以开始取证调查的另一个节点。由于分析是在受影响容器的副本中进行的，因此任何可能访问原始容器的攻击者都不会知道此类分析。

此功能使用新引入的 CRI API，因此 kubelet 可以请求一次性调用来创建检查点。

通过/checkpoint端点请求创建快照，并将以.tar格式（即checkpoint-<podFullName>-<containerName>-<timestamp>.tar）存储在--root-dir（默认为/var/lib/kubelet/checkpoints）下。

#2831 Kubelet OpenTelemetry 跟踪

阶段： Graduating 到 Alpha
特征组： 节点
特征门： KubeletTracing
默认值： false

根据APIServer 的 KEP-647，此增强功能将 OpenTelemetry 跟踪添加到kubelet的 GRPc 调用上。

这些跟踪可以提供有关节点级别交互的洞察力，例如，kubelet与容器运行时之间的交互。

这将帮助管理员调查在创建或删除 Pod、将卷附加到容器等时发生在节点级别的延迟问题。

#3085 pod 沙箱就绪状态

阶段： Graduating 到 Alpha
特征组： 节点
特征门： PodHasNetworkCondition
默认值： false

Pod 定义中添加了一个新条件，PodHasNetwork以让 Kubelet 指示 Pod 沙箱已创建，并且 CRI 运行时已配置其网络。此条件标志着 pod 生命周期中的一个重要里程碑，类似于ContainersReady或Ready条件。

到目前为止，例如，一旦 Pod 成功调度触发 PodScheduled 条件，就没有其他关于网络初始化的特定条件。

这个新条件将有利于集群操作员在创建 Pod 沙箱时配置组件，如 CSI 插件、CRI 运行时、CNI 插件等。

#3327 CPU 管理器策略：套接字对齐

阶段： Net New to Alpha
特征组： 节点
特征门： CPUManagerPolicyAlphaOptions
默认值： false

这为 CPUManager 添加了一个新的静态策略，align-by-socket 有助于在 NUMA 边界对齐 CPU 分配会导致从不同套接字分配 CPU 的情况下实现可预测的性能。

#2254 cgroup v2

阶段： Graduating 到 Stable
特征组： 节点
特征门： N/A

此增强功能涵盖了使 Kubernetes 与 Cgroups v2 兼容的工作，从配置文件开始。

检查新的配置值，因为值的范围会有一些变化。例如，cpu.weight值将从 [2-262144] 更改为 [1-10000]。

#277 临时容器

阶段： Graduating 到 Stable
特征组： 节点
特征门： EphemeralContainers
默认值: true

临时容器是调试正在运行的 pod 的好方法。虽然您无法在创建后将常规容器添加到 pod，但您可以使用kubectl debug。

#1029 临时存储配额

阶段： Graduating 到 Beta
功能组： 节点
功能门： LocalStorageCapacityIsolationFSQuotaMonitoring
默认值： true

一种计算配额的新机制，它比定期扫描临时卷更有效、更准确。

#2238为探测添加可配置的宽限期

阶段： Major 到 Beta
功能组：节点
功能门： ProbeTerminationGracePeriod
默认值： true

此增强介绍livenessProbe对象内部引入了第二个字段terminationGracePeriodSeconds，以区分两种情况：

  • 在正常情况下，Kubernetes 应该等待多长时间才能杀死容器
  • 因livenessProbe失败，何时被杀死？

#2413默认为 seccomp

阶段： Graduating 到 Beta
功能组： 节点
功能门： SeccompDefault
默认值： true

Kubernetes 现在提高了容器的安全性，默认使用Seccomp配置文件执行它们。

Kubernetes 1.25 中的调度

#3094在计算 PodTopologySpread Skew 时考虑污点/容忍度

阶段： Graduating 到 Alpha
特征组： 调度
特征门： NodeInclusionPolicyInPodTopologySpread
默认值： false

topologySpreadConstraints字段允许您跨节点分散工作负载；它与maxSkew一起这样做，它表示两个给定拓扑域之间 pod 数量的最大差异。

新添加的字段NodeInclusionPolicies允许设置NodeAffinity和NodeTaint（值：Respect/Ignore），以在计算此 pod 拓扑扩展偏斜时考虑污点和容忍度。

  • NodeAffinity: Respect表示节点匹配nodeAffinity并将nodeSelector包含在倾斜过程中。
  • NodeAffinity: Ignore（默认）表示将包含所有节点。
  • NodeTaint: Respect意味着容忍传入 pod 的受污染节点以及常规节点将包含在 skew 过程中。
  • NodeTaint: Ignore（默认）表示将包含所有节点。

这将防止某些 pod 进入意外的 Pending 状态，因为倾斜约束将它们分配给具有污点或容忍度的节点。

#3243滚动升级后遵循 PodTopologySpread

阶段： Net New to Alpha
功能组： 调度
功能门： MatchLabelKeysInPodTopologySpread
默认值： false

PodTopologySpread有助于更好地控制彼此相关的 Pod 分布的均匀程度。然而，当推出一组新的 Pod 时，现有的（即将消失的）Pod 被包含在计算中，这可能会导致未来的 Pod 分布不均。

由于 Pod 规范中的一个新字段及其计算算法，此增强功能增加了考虑 Pod 定义中包含的任意标签的灵活性，使控制器能够在计算 spread 之前创建更精确的 Pod 集。

在下面的配置中，我们可以观察到两个相关的字段，labelSelector和matchLabelKeys.到目前为止，只有labelSelector确定了拓扑域中的 Pod 数量。通过添加一个或多个键matchLabelKeys，就像已知的pod-template-hash一样，，控制器可以区分同一个Deployment的不同ReplicaSets下的 Pod ，并以更准确的方式计算散布。

apiVersion: v1
kind: Pod
Metadata:
 name: example-pod
Spec:
 # Configure a topology spread constraint
 topologySpreadConstraints:
   - maxSkew: <integer>
     minDomains: <integer> # optional; alpha since v1.24
     topologyKey: <string>
     whenUnsatisfiable: <string>
     labelSelector: <object>
     matchLabelKeys: <list> # optional; alpha since v1.25
 ### other Pod fields go here

此功能可能不会对你产生影响，甚至不会改变集群的性能。但是，如果您想知道为什么 Pod 没有按照您想要的方式分布，那么就有答案了。

#785 kube-scheduler ComponentConfig 毕业到 GA

阶段： Graduating 到 Stable
特征组： 调度
特征门： NA

ComponentConfig是一项持续的努力，旨在使组件配置更加动态和通过 Kubernetes API 直接访问。

在这个版本中，删除了几个插件：

  • KubeSchedulerConfigurationv1beta2已弃用，请迁移到v1beta3或 v1。
  • 调度程序插件SelectorSpread已删除，使用PodTopologySpread代替。

#3022 PodTopologySpread 中的最小域

阶段： Graduating 到 Beta
功能组： 调度
功能门： MinDomainsInPodTopologySpread
默认值： true

一个新的minDomains子资源建立了应被视为可用的域的最小数量，即使它们在调度一个新的 Pod 时可能不存在。因此，在必要时，域将被扩展，集群自动扩展器将自动请求域中的新节点。

Kubernetes 1.25 存储

#1710 SELinux 使用挂载选项重新标记

阶段： Graduating 到 Alpha
特征组： 存储
特征门： SELinuxMountReadWriteOncePod
默认值： false

此功能旨在加快PersistentVolumes使用 SELinux 的安装速度。通过context在挂载时使用该选项，Kubernetes 将在整个卷上应用安全上下文，而不是递归地更改文件上的上下文。此实现有一些注意事项，并且在第一阶段将仅应用于由PersistentVolumeClaimswith 支持的卷ReadWriteOncePod。

这个特性是为了使用SELinux加速PersistentVolumes的挂载。通过在挂载时使用 context 选项，Kubernetes将对整个卷应用安全上下文，而不是递归地更改文件的上下文。这个实现有一些注意事项，在第一阶段将只应用于ReadWriteOnce模式的PersistentVolumeClaims Pod 卷。

#3107NodeExpand Secret

阶段： Graduating 到 Alpha
特征组： 存储
**特征门：CSINodeExpandSecret
**默认值：** false

存储是必需的，不仅对于有状态的应用程序，对于集群节点也是如此。在使用storageclass Secrets的 Kubernetes 之前的版本中，已经可以使用凭据扩展卷。但是，当将存储挂载到节点上时，在执行NodeExpandVolume操作时，我们没有传递这些凭证的机制。

这些新的增强通过利用StorageClass定义中的两个新注释，支持将secretRef字段传递给 CSI 驱动程序:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-storage-sc
parameters:
  csi.storage.k8s.io/node-expand-secret-name: secret-name
  csi.storage.k8s.io/node-expand-secret-namespace: mysecretsns

请参阅 KEP:向 NodeExpandVolume 请求添加 SecretRef 字段 以了解更多信息。

#3333在 PersistentVolumeClaims (PVC) 中协调默认 StorageClass

阶段： Net New to Alpha
功能组： 存储
功能门： RetroactiveDefaultStorageClass
默认值： false

这种增强巩固了在没有StorageClass的情况下创建 pvc 时的行为，使用默认类向 pvc 添加显式注释。这有助于在集群管理员更改默认存储类时进行管理，在删除旧存储类和设置新存储类之间强制执行一段没有默认存储类的时间。

当设置新的默认值时启用该特性，所有没有StorageClass的 pvc 都将被设置为默认 StorageClass。

#361本地临时存储资源管理

阶段： Graduating 到 Stable
特征组： 存储
特征门： LocalStorageCapacityIsolation
默认值： true

自从它在 Kubernetes 1.7 的 Alpha 中首次引入以来已经有很长一段时间了，这允许我们通过配置requests.ephemeral-storage和limits.ephemeral-storage以与 CPU 和内存类似的方式来限制 Pod 使用的临时存储。

Kubernetes 将驱逐容器超出其配置限制和请求的 Pod 。至于 CPU 和内存，调度程序会在将 Pod 调度到节点上之前，根据可用的本地存储检查 Pod 的存储需求。此外，管理员可以配置ResourceQuotas来设置对命名空间的总requests/limits设置限制，并配置LimitRanges来配置 Pod 的默认限制。

#625 CSI 迁移~核心

阶段： Graduating 到 Stable
特征组： 存储
特征门： CSIInlineVolume
默认值： true

存储插件原本是 in-tree，在 Kubernetes 代码库内部，增加了基础代码的复杂性并阻碍了可扩展性。

正在努力将所有这些代码移动到可加载插件，这些插件可以通过容器存储接口与 Kubernetes 交互。

大多数PersistentVolume类型已被弃用，只剩下这些：

  • cephfs
  • csi
  • fc
  • hostPath
  • iscsi
  • local
  • nfs
  • rbd

#1488 CSI 迁移 – GCE

阶段： Graduating 到 Stable
特征组： 存储
特征门： CSIMigrationGCE
默认值： true

这将 GCE（Google Container Engine）中对 Persistent Disk 的支持移到了树外 pd.csi.storage.gke.io Container Storage Interface (CSI) Driver（需要安装在集群上）。

#596 CSI 临时卷

阶段： Graduating 到 Stable
特征组： 存储
特征门： CSIInlineVolume
默认值： true

目前只能通过 PV/PVC 引用 CSI 卷。这适用于远程持久卷。此功能还引入了将 CSI 卷用作本地临时卷的可能性。

#1487 CSI 迁移~AWS

阶段： Graduating 到 Stable
特征组： 存储
特征门： CSIMigrationAWS
默认值： true

AWS EBS 容器存储接口 (CSI) 驱动程序的所有插件操作现在都重定向到树外的ebs.csi.aws.com驱动程序。

#1491 CSI 迁移~vSphere

阶段： Graduating 到 Beta
功能组： 存储
功能门： CSIMigrationvSphere
默认值： false

vSphere 的 CSI 驱动程序已经稳定了一段时间。现在，所有插件操作vspherevolume现在都重定向到树外的csi.vsphere.vmware.com驱动程序。

#2589 CSI 迁移~Portworx

阶段： Graduating 到 Beta
功能组： 存储
功能门： CSIMigrationPortworx
默认值： false

Portworx 容器存储接口 (CSI) 驱动程序的所有插件操作现在都重定向到树外的pxd.portworx.com驱动程序。

Kubernetes 1.25 中的其他增强功能

#2876 CRD 验证表达式语言

阶段： Graduating 到 Beta
功能组： api-machinery
功能门： CustomResourceValidationExpressions
默认值： true

此增强功能实现了自定义资源定义 (CRD) 的验证机制，作为对基于 webhook 的现有机制的补充。

这些验证规则使用通用表达式语言 (CEL)并包含在CustomResourceDefinition模式中，使用x-kubernetes-validations extension.

提供了两个新指标来跟踪编译和评估时间：cel_compilation_duration_seconds和cel_evaluation_duration_seconds.

#2885 服务器端未知字段验证

阶段： Graduating 到 Beta
功能组： api-machinery
功能门： ServerSideFieldValidation
默认值： true

目前，您可以使用kubectl -validate=true指示如果请求在对象上指定未知字段，则该请求应失败。这个增强总结了在 kube-apiserver 上实现验证的工作。

#3203自动刷新官方 CVE 提要

阶段： New to Alpha
功能组：安全
功能门： N/A

假设您需要一个包含 Kubernetes 相关信息的 cve 列表，您希望通过编程方式获取这些信息。或者，为了让您安心，您希望浏览已修复漏洞的列表，并知道官方 K8s 团队正在发布这些漏洞。

更进一步，你可能是 Kubernetes 的供应商，想要通知他们的客户哪些 cve 是最近公布的，需要修复等等。

无论哪种方式，这种增强都不是在集群中启用的，而是通过 web 资源使用的。您只需要在漏洞公告中查找official-cve-feed标签。

请参阅 KEP:auto-refreshing-official-cve-feed

#2802 权威地识别 Windows pod API 在准入级别

阶段： Graduating 到 Stable
特征组： windows
特征门： IdentifyPodOS
默认值： true

此增强功能OS向 PodSpec 添加了一个字段，因此您可以定义 pod 应该在哪个操作系统上运行。这样，Kubernetes 就有更好的上下文来管理 Pod。

总结

这就是 Kubernetes 1.25 的全部内容！一如既往的精彩；如果您打算使用这些功能的其中之一，请准备好升级集群。

译自：https://u.kubeinfo.cn/wSuvoL
译者：#公众号：进击云原生

本文由mdnice多平台发布

posted @ 2022-08-24 07:46  进击云原生  阅读(97)  评论(0)  编辑  收藏  举报