此版本带来了 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 和功能，包括：

  • 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）
  • 其他变化：
  • ​​PodSecurityPolicy​​ beta 准入插件，自 1.21 起已弃用，现已删除。
  • 已删除对多个 in-tree 卷插件的支持：

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

​​#5​​ PodSecurityPolicy

阶段： 弃用
功能组： auth

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

就在刚刚 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 直接访问。

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

  • KubeSchedulerConfiguration​​v1beta2​​​已弃用，请迁移到​​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 将在整个卷上应用安全上下文，而不是递归地更改文件上的上下文。此实现有一些注意事项，并且在第一阶段将仅应用于由​​PersistentVolumeClaims​​​with 支持的卷​​ReadWriteOncePod​​。

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

​​#3107​​NodeExpand 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:

请参阅 ​​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 的全部内容！一如既往的精彩；如果您打算使用这些功能的其中之一，请准备好升级集群。