Kubernetes 1.24 的发布日期从 4 月 19 日 移至 5 月 3 日^[1]。现已正式发布。

此版本带来了 46 项增强，与Kubernetes 1.23 中的 45^[2]和Kubernetes 1.22 中的 56 相当^[3]。在这 46 项增强功能中，13 项正在升级到稳定版，14 项是不断改进的现有功能，13 项是全新的，6 项是已弃用的功能。

在这个版本中，最大的变动是 删除 Dockershim^[4]，这是确保 Kubernetes 项目未来的必要步骤。注意此版本中的所有弃用和删除^[5]！

此版本中包含的新功能通常很小，但有可能改变我们与 Kubernetes 的交互方式，例如新的Network Policy Status^[6]字段、新的 CSI 卷健康监控^[7]或对 CronJobs 的 TimeZone 支持^[8]。此外，其他功能将使集群管理员的生活更轻松，例如 StatefulSets 的 maxUnavailable^[9] 或 non-graceful node shutdown^[10]。

使得这个版本锦上添花的是所有达到 GA 状态的伟大功能。这包括历史悠久的功能，例如CSI 卷扩展^[11]、PodOverhead^[12]、存储容量跟踪^[13]和Service Type=LoadBalancer Class^[14]等等。

让我们开始了解 Kubernetes 1.24 中的新功能。

Kubernetes 1.24

这些是在此版本中对我们来说最令人兴奋的功能：

Dockershim 移除

随着项目的增长，他们需要放弃他们的遗留功能以确保他们的未来。Dockershim 是 Kubernetes 的容器运行时，但它已被更好的 CRI 可插拔系统所取代。现在 Dockershim 已被移除，许多开发人员和集群管理员将不得不进行不方便但必要的迁移。

CSI 卷健康监控

能够加载一个检查持久卷健康状况的边车是一个受欢迎的补充。现在，集群管理员将能够对事件做出更好、更快的反应，比如在 Kubernetes 以外删除持久性卷。这绝对会增加 Kubernetes 集群的可靠性。

网络策略状态

创建遵循零信任方法的网络策略^[15]是一种容器安全最佳实践。^[16]但是，有时您会遇到难以调试的错误，并且最终打开策略的次数超出了您的预期。能够调试这些情况将使 Kubernetes 集群更加安全。

Windows 可使用 readiness 定义和工具集成

自从在 Kubernetes 1.14 中引入以来，对 Windows 的支持在一个又一个版本中不断增长，将 Kubernetes 开放给许多原本不会考虑它的公司。

使用 Kubernetes 1.24 定义的这个标准，将更容易比较 Kubernetes 供应商之间的 Windows 支持。希望这将使在这些环境中采用 Kubernetes 的不确定性降低一些。

#108004^[17] kubelet：公开 OOM 指标

这是一项不符合增强条件的微小改进，但会产生重大影响。从 1.24 开始，kubelet 提供了一个新的 Prometheus 指标，用于记录容器中发生的OutOfMemory 事件的数量^[18]。当内存限制不能满足容器的使用和需求时，这提供了对 Kubernetes 操作中反复出现的问题的更多可见性。

使用这个新指标，SRE 可以更好地了解问题的最终原因，并更好地确定它是反复出现的问题还是边缘情况。更快的故障排除。

弃用

API 和功能移除

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

• 移除了 Dockershim。
• 删除了实验性的动态日志清理功能。
• 删除了仪表板的集群插件。
• cloud-provider从包中删除了不安全的服务配置，该包由cloud-controller-managers使用。
• 已弃用低于 7.0u2 的 VSphere 版本。
• 已弃用 in-tree azure 插件。
• 已弃用metadata.clusterName字段。
• 已删除Client.authentication.k8s.io/v1alpha1 ExecCredential。
• node.k8s.io/v1alpha1 RuntimeClassAPI 不再提供，请使用/v1.
• 去掉tolerate-unready-endpointsService 中的注解，改用Service.spec.publishNotReadyAddresses。
• 已弃用Service.Spec.LoadBalancerIP。
• 已弃用的CSIStorageCapacityAPI 版本v1beta1，请使用v1.
• 删除VolumeSnapshot v1beta1，使用v1。
• 功能门：
• 已删除ValidateProxyRedirects。
• 已删除StreamingProxyRedirects。
• kube apiserver：
• 弃用了--master-countflag 和--endpoint-reconciler-type=master-countreconciler，转而使用 lease reconciler。
• 删除了地址标志--address、--insecure-bind-address和。--port和--insecure-port
• Kubeadm：
• 默认情况下启用功能门：UnversionedKubeletConfigMap。
• kubeadm.k8s.io/v1beta2已弃用，v1beta3用于新集群。
• 去掉了node-role.kubernetes.io/master标签。
• Kube-controller-manager：
• 删除了标志--address和--port.
• Kubelet：
• 弃用标志--pod-infra-container-image。
• 已删除DynamicKubeletConfig。

您可以在Kubernetes 1.24 发行说明^[19]中查看完整的更改列表。此外，我们推荐Kubernetes Removals and Deprecations In 1.24^[20]文章，以及为将来保留已弃用的 API 迁移指南^[21]。

#2221^[22] Dockershim 移除

阶段：主要变化为稳定
功能组：node

Dockershim 是 kubelet 代码库中的内置容器运行时。但是，随着容器运行时接口 (CRI) 的引入，可以将容器运行时与kubelet代码库分离。

此外，这种解耦是一种很好的做法，可以简化开发人员和集群维护人员的维护。

存在替代方案，因此这并不意味着在 Kubernetes 中失去功能。您可能会发现下面这些资源会很有帮助：

• 从 dockershim 迁移^[23]
• Kubernetes 正在从 Dockershim 继续前进^[24]
• Dockershim 移除常见问题^[25]
• 您的集群准备好使用 v1.24 了吗？^[26]

#281^[27]动态 Kubelet 配置

阶段：已删除
功能组：node

自 Kubernetes 1.11 以来处于测试阶段后，Kubernetes 团队决定^[28]弃用DynamicKubeletConfig而不是继续其开发。

#3136^[29] Beta API 默认关闭

阶段：毕业到稳定
功能组：architecture

默认情况下会启用被认为不稳定的 Beta API。这有一个好的方面，因为它加速了这些功能的采用。然而，这为几个问题打开了大门。例如，如果一个测试版 API 有一个错误，它将出现在 90% 的已部署集群上。

从 Kubernetes 1.24 开始，新的 beta API 将默认禁用。

此更改不会影响功能门。

您可能需要查看KEP^[30]以了解更多基本原理和实施细节。

#1164^[31]弃用并删除 SelfLink

阶段：毕业到稳定
功能组：api-machinery
功能门：RemoveSelfLink
默认值：true

启用此功能后，.metadata.selfLink字段仍然是 Kubernetes API 的一部分，但始终未设置。

#1753^[32] Kubernetes 系统组件日志清理

阶段：已删除
功能组：instrumentation

日志清理是在 Kubernetes 1.20 中^[33] 作为 alpha 引入的。在对某些版本进行评估后，instrumentation SIG^[34] 决定在 Kubernetes 1.23^[35]中升级到稳定的静态分析将是一种更好的方法。

#2845^[36]弃用 Kubernetes 组件中的 klog 特定标志

阶段：毕业到 Beta
功能组：instrumentation

这种增强是简化组件中日志记录的更大努力的一部分。第一步是删除 klog 中的一些标志^[37]。

Kubernetes 1.24 API

#1904^[38] Efficient Watch Resumption

阶段：毕业到稳定
功能组：api-machinery
功能门：EfficientWatchResumption
默认值：true

从现在开始，kube-apiserver可以在重启后更快地初始化它的watch cache

#2885^[39] 字段校验

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

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

#2887^[40] openapi 枚举类型到 beta

阶段：毕业到 Beta
功能组：api-machinery
功能门：OpenAPIEnum
默认值：true

此增强功能改进了 Kubernetes OpenAPI 生成器，因此它可以识别标记为的类型+enum并自动检测枚举的可能值。

#2896^[41] OpenAPI v3

阶段：毕业到 Beta
功能组：api-machinery
功能门：OpenApiv3
默认值：true

此功能增加了kube-apiserver将 Kubernetes 和类型作为 OpenAPI v3 对象提供服务的支持。一个新的/openapi/v3/apis/{group}/{version}端点可用。它为每个资源提供一个模式，而不是将所有内容聚合成一个模式。

Kubernetes 1.24 中的应用程序

#961^[42] maxUnavailable for StatefulSets

阶段：Alpha
功能组：apps
功能门：MaxUnavailableStatefulSet
默认值：false

StatefulSets支持有状态的应用程序，因为它们需要稳定的持久存储、唯一的网络标识符或有序的滚动更新，仅举几个用例。

在最后一种情况下，当执行滚动更新时，Pod 将被删除并一次重新创建一个。这最大限度地降低了丢失应用程序实例的风险，并最大限度地提高了可用性和在出现问题时回滚的机会。

从现在开始，子资源maxUnavailable将控制一次删除和重新创建多少个应用程序 Pod，这可能会加快应用程序的滚动更新。

为避免意外，在滚动更新有状态应用程序之前，请记住检查此新参数的值。请记住，一个非常高的值可能会将我们的滚动部署转换为重新创建的部署，从而使我们完全失去服务（在最好的情况下是暂时的）。

#3140^[43] CronJob 中的时区支持

阶段： Alpha
功能组： apps
功能门： CronJobTimeZone
默认值： false

此功能尊重延迟的请求以支持CronJob资源中的时区。到目前为止，CronJobs创建的Jobs被设置在同一时区中，时区是kube-controller-manager所在的时区。

计算Jobs需要开始的时间的过程已经结束，找到正确的时区可能是新挑战。

#2214^[44] Job API 中的 Indexed Job 语义

阶段：毕业到稳定
功能组：应用程序
功能门： IndexedJob
默认值： true

Kubernetes 1.21^[45] 中引入了索引作业，以便更轻松地安排高度可并行化的作业。

此增强功能将完成索引^[46]添加到具有固定完成计数的 Job 的 Pod 中，以支持运行并行程序。

#2232^[47] batch/v1：向 Jobs API 添加 suspend 字段

阶段：毕业到稳定
功能组：应用程序
功能门： JobReadyPods
默认值： true

从 Kubernetes 1.21 开始，可以通过将 Job 的字段.spec.suspend设置为true，暂时挂起^[48]作业，稍后通过将其设置回false来恢复作业。

#2879^[49] 跟踪 Job 状态中的就绪 Pod

阶段：毕业到 Beta
功能组：应用程序
功能门： JobReadyPods
默认值： true

此增强功能添加了Job.status.ready，计算 Job 具有Ready condition 的 Pod 数量，类似于现有的active、succeeded和failed字段。该字段可以减少监听 Pod 更新的需要，以便更准确地了解当前状态。

Kubernetes 1.24 认证

#2784^[50] CSR Duration

阶段：毕业到稳定
特征组： auth
特征门： CSRDuration
默认值： true

一个新字段ExpirationSeconds被添加到 CertificateSigningRequestSpec，该字段接受的最小值为 600 秒（10 分钟）。这样，clients可以为certificates定义比默认的一年更短的期限。

#2799^[51]减少基于 Secret 的服务帐户令牌

阶段：毕业到 Beta
功能组： auth
功能门：LegacyServiceAccountTokenNoAutoGeneration
默认值： true

现在TokenRequest API^[52] 从 Kubernetes 1.22 开始就已经稳定了，是时候进行一些清理并推广使用这个 API 来取代旧的令牌了。

到目前为止，KubernetesSecret在创建Pod. 该令牌Secret包含访问 API 的凭据。

现在，API 凭证直接通过 TokenRequest API 获得，并使用预计的卷安装到 Pod 中。此外，这些令牌将在其关联的 Pod 被删除时自动失效。如果需要，您仍然可以手动创建令牌secrets。

跟踪和清理现有令牌的功能将添加到 Kubernetes 的未来版本中。

Kubernetes 1.24 中的网络

#2943^[53]Network Policy 状态

阶段： Alpha
特征组：网络
特征门： NetworkPolicyStatus
默认值： false

不同的 CNI 提供商实现网络策略资源的方式不同。而且他们可能以不同的顺序实现特性。这可能导致当前 CNI 提供程序不遵守网络策略，最糟糕的是，没有通知用户有关情况。

新的Status子资源将允许用户收到关于NetworkPolicy及其功能是否被正确解析的反馈，并帮助他们理解为什么某个特定功能不起作用。

这将有助于解决以下问题：

• 出口网络策略的端口范围，可能尚未由提供程序实现。
• 用户创建网络策略的新功能似乎不起作用。
• 在交付准备环境中开发的网络策略在生产环境中的工作方式似乎不同，生产环境可能运行在稍微老一点的版本上。

总而言之，这是向前迈出的一步，这将使 Kubernetes 网络问题的故障排除变得不那么痛苦。

有关此新功能的更多信息，请查看网络策略状态 KEP^[54]。

#3070^[55]为动态和静态 IP 分配保留 Service IP 范围

阶段： Alpha
特征组：网络
特征门： ServiceIPStaticSubrange
默认值： false

Kubernetes Service 是一种公开在一组 Pod 上运行的应用程序的抽象方式。Service 有一个虚拟的 ClusterIP，允许跨不同 Pod 负载均衡流量。可以分配此 ClusterIP：

• 动态地，集群将在配置的服务 IP 范围内选择一个。
• 静态地，用户将在配置的服务 IP 范围内设置一个 IP。

为服务设置静态 IP 地址可能非常有用，但也非常危险。目前，没有办法预先知道一个 IP 地址是否已动态分配给现有服务。

此功能将降低使用静态和动态 IP 分配的服务之间发生 IP 冲突的风险，并在同一类型下保持向后兼容性。

它的实现基于服务网络的分段，作为字符串参数传递给--service-cluster-ip-range标志，当前用于将 IP 地址分配给服务，分为两个波段。

优选地，下部将优选用于静态 IP 地址，而上部应专用于动态分配的 IP。但是，在上限用尽的情况下，它将继续使用下限。

计算这些值的公式可以在保留服务 IP 范围 KEP^[56]中找到，但我们将其总结为静态频段将包含至少 16 个 IP，但不会超过 256 个。

#1435^[57]支持 type=LoadBalancer 的服务中的混合协议

阶段：毕业到 Beta
功能组：网络
功能门： MixedProtocolLBService
默认值： true

此增强功能允许 LoadBalancer 服务在同一端口（UDP、TCP）下服务不同的协议。例如，在同一端口上为 DNS 或 SIP 服务器提供 UDP 和 TCP 请求。

#2086^[58]服务内部流量策略

阶段：毕业到 Beta
功能组：网络
功能门： ServiceInternalTrafficPolicy
默认值： true

现在可以在Service对象的spec.trafficPolicy字段上设置以优化集群流量：

• 使用Cluster，路由将像往常一样运行。
• 当设置为Topology时，它将使用拓扑感知路由^[59]。
• 使用PreferLocal，它将流量重定向到同一节点上的服务。
• 使用Local，它只会将流量发送到同一节点上的服务。

Kubernetes 1.24 节点

\# 688^[60] PodOverhead

阶段：毕业到稳定
特征组：节点
特征门： PodOverhead
默认值： true

除了请求的资源之外，您的 pod 还需要额外的资源来维护其运行时环境。

启用此功能后，Kubernetes 在调度 Pod 时会考虑此开销。Pod Overhead 是在准入时计算和固定的，它与 Pod 的 RuntimeClass 相关联。

#2133^[61] Kubelet 凭证提供者

阶段：毕业到 Beta
功能组：节点
功能门： DisableKubeletCloudCredentialProviders
默认值： true

此增强功能将树内容器镜像注册表凭据提供程序替换为外部且可插入的新机制。

#2712^[62] PriorityClassValueBasedGracefulShutdown

阶段：毕业到 Beta
功能组：节点
功能门： GracefulNodeShutdownBasedOnPodPriority
Default value: false

从现在开始，您可以提供更多的时间停止为高优先级的 Pods 时，注意是优雅的关机。此增强功能增加了根据 Pod 优先级类值为 Pod 提供不同停止时间的可能性。

在 Kubernetes 1.24 中，指标graceful_shutdown_start_time_seconds和graceful_shutdown_end_time_seconds可用于监控节点关闭。

#2727^[63] gRPC 探针

阶段：毕业到 Beta
功能组：节点
功能门： GRPCContainerProbe
Default value: true

此增强功能允许为 Pod 配置 gRPC（HTTP/2 over TLS）liveness 探测。

Kubernetes 1.16 中添加的 liveness 探针^[64] 允许定期检查应用程序是否仍然活跃。

在Kubernetes 1.23^[65]中，添加了对gRPC协议的支持。

Kubernetes 1.24 中的调度

#3022^[66] minPodTopologySpread 中的域

阶段： Alpha
特征组：调度
特征门： MinDomainsInPodTopologySpread
默认值： false

当新的 Pod 被分配给节点时，PodTopologySpread 子资源^[67]通过maxSkew参数定义 Pod 的分布有多不均匀。根据可用资源的数量，可能无法 maxSkew满足要求。使用WhenUnsatisfiable=DoNotSchedule可能会导致调度程序拒绝分配这些新的 Pod，因为没有足够的可用资源。

另一方面，为了避免浪费资源，Cluster Autoscaler 可以根据其利用率来扩大和缩小域。但是，当域缩小到0时，调度程序执行的计算中包含的域数可能无法真实反映可用资源的总数。换句话说，已经缩小到0的域对于调度程序变得不可见。

新的minDomains子资源建立了最小数量的域，这些域应该算作可用，即使它们在调度新 Pod 时可能不存在。因此，在必要时，域将被扩展，并且该域中的新节点将由集群自动扩展程序自动请求。

深入挖掘此功能的minPodTopologySpread KEP^[68]以了解更多详细信息。

#902^[69] 非抢占优先级到 GA

阶段：毕业到稳定
特征组：调度
特征门： NonPreemptingPriority
默认值： true

目前，PreemptionPolicy默认为PreemptLowerPriority，这允许高优先级的 pod 抢占低优先级的 pod。

此增强添加了PreemptionPolicy: Never选项，因此 Pod 可以在较低优先级的 pod 之前放置在调度队列中，但它们不能抢占其他 pod。

#2249^[70] Pod 关联 NamespaceSelector 到 GA

阶段：毕业到稳定
特征组：调度
特征门： PodAffinityNamespaceSelector
默认值： true

通过在deployment中定义节点亲和性^[71]，您可以限制您的 pod 将被安排在哪些节点上。例如，部署在已经运行 Pod 且label-value带有example-label的节点。

此增强功能添加了一个namespaceSelector字段，因此您可以通过标签而不是名称来指定命名空间。使用此字段，您可以动态定义命名空间集。

Kubernetes 1.24 存储

#2268^[72]非正常节点关闭

阶段： Alpha
特征组：存储
特征门： NonGracefulFailover
默认值： false

当节点关闭但 Kubelet 的 Node Shutdown Manager 未检测到时，属于 StatefulSet 的 pod 将在关闭节点上停留在终止状态，无法移动到新的运行节点。

此功能解决了未正确检测到的节点关闭情况。在这种情况下，Pod 将被强制删除，触发 VolumeAttachments 的删除，并在新的运行节点上创建新的 Pod，以便应用程序继续运行。

这也可以应用于节点处于不可恢复状态的情况，例如硬件故障或操作系统损坏。

out-of-service为了使这项工作，用户必须在确认节点已关闭或处于不可恢复状态后应用一次污点。将 NoExecute 效果添加到先前的 taint 中，例如out-of-service=nodeshutdown:NoExecute或out-of-service=hardwarefailure:NoExecute，将驱逐 Pod，这些将在其他节点中启动。

要恢复节点，用户需要out-of-service在 pod 移动到新节点后手动删除污点。

#3141^[73]控制源 PVC 和目标 PVC 之间的 volume 模式转换

阶段： Alpha
特征组：存储
特征门： N/A

用户可以利用 Kubernetes 1.20 中 GA 提供的 VolumeSnapshot 功能，创建一个 PersistentVolumeClaim 或 PVC，将其从以前的 VolumeSnapshot 转换成现在的样子。不幸的是，没有对卷模式转换进行验证。

此特性可防止在此类操作期间对卷模式进行未经授权的转换。尽管在内核中没有已知的 CVE，允许恶意用户利用它，但这个特性旨在消除这种可能性，以防万一。

#1432^[74] CSI 卷健康监控

阶段： Alpha
特征组：存储
特征门： CSIVolumeHealth
默认值： false

CSI 驱动程序现在可以加载外部控制器作为检查卷健康状况的 sidecar，并且它们还可以在NodeGetVolumeStatsKubelet 已经用于收集卷信息的函数中提供额外信息。

在 Kubernetes 1.24 中，卷健康信息作为 kubelet VolumeStats指标公开。该kubelet_volume_stats_health_status_abnormal指标将有一个persistentvolumeclaim标签，其值如果为1表示卷不健康，0为健康。

#284^[75] CSI 卷扩展

阶段：毕业到稳定
特征组：存储
特征门: ExpandPersistentVolumes默认值： true
特征门: ExpandInUsePersistentVolumes 默认值： true
特征门: ExpandCSIVolumes 默认值: true

这组功能分别从 Kubernetes 1.11、1.15 和 1.16 开始处于测试阶段。在 Kubernetes 1.24 中，调整持久卷大小^[76]的能力最终被认为是稳定的。

#1472^[77]存储容量跟踪

阶段：毕业到稳定
特征组：存储
特征门： CSIMigrationAzureFile 默认值：true
特征门: CSIMigration 默认值：true

此增强功能试图防止在没有足够可用空间的情况下将 pod 调度到连接到 CSI 卷的节点上。

#1489^[78] OpenStack in-tree 到 CSI 驱动程序迁移

阶段：毕业到稳定
特征组：存储
特征门： CSIMigrationOpenStack
默认值： true

此增强功能总结了将 OpenStack Cinder 代码^[79]移出主要 Kubernetes 二进制文件（out-of-tree）的工作。

#1490^[80] Azure disk in-tree 到 CSI 驱动程序迁移

阶段：毕业到稳定
特征组：存储
特征门： CSIMigrationAzureDisk
默认值： true

此增强功能总结了将 Azure 磁盘代码^[81]移出主要 Kubernetes 二进制文件（out-of-tree）的工作。

#1885^[82] Azure file in-tree 到 CSI 驱动程序迁移

阶段：毕业到 Beta
功能组：存储
功能门： InTreePluginAzureDiskUnregister
默认值： true

此增强功能总结了将 Azure 文件代码^[83]移出主要 Kubernetes 二进制文件（out-of-tree）的工作。

#1495^[84]Volume 填充器

阶段：毕业到 Beta
功能组：存储
功能门： AnyVolumeDataSource
默认值： true

在 Kubernetes 1.18 中引入，这种增强为用户创建预填充卷奠定了基础。例如，使用操作系统映像预填充虚拟机的磁盘，或者启用数据备份和恢复。

为了实现这一点，将取消^[85]当前对持久卷的 DataSource 字段的验证，允许它将任意对象设置为值。关于如何填充卷的实现细节被委托给专门构建的控制器。

#2644^[86]始终遵守 reclaim 政策

阶段：毕业到 Beta
功能组：存储
功能门： HonorPVReclaimPolicy
默认值： true

该增强修复了一个问题，即在某些绑定持久卷(PV)-持久卷声明(PVC)对中，PV-PVC 删除的顺序决定 PV 删除回收策略是否得到遵守。

Kubernetes 1.24 中的其他增强功能

#2551^[87] kubectl 返回码规范化

阶段： Alpha
功能组： cli
功能门： N/A

这不仅仅是一个特性，它是一种标准化不同子命令kubectl支持并将支持的返回码的尝试。这旨在促进任务的自动化，并将更好地理解我们的命令结果。

#2590^[88]在 kubectl 中添加子资源支持

阶段： Alpha
功能组： cli
功能门： N/A

一些 kubectl 命令，如get、patch、edit和replace现在将包含一个新标志--subresource=[subresource-name]，这将允许获取和更新status所有scaleAPI 资源的子资源。

您现在可以停止使用复杂的 curl 命令直接更新子资源。

#1959^[89] Service type=LoadBalancer

阶段：毕业到稳定
特征组： cloud-provider
特征门： ServiceLoadBalancerClass
默认值： true

此增强功能允许您利用Service Type=LoadBalancer集群中的多个实现。

#2436^[90] leader 迁移到 GA

阶段：毕业到稳定
特征组： cloud-provider
特征门： ControllerManagerLeaderMigration
默认值： true

正如我们已经讨论了一段时间^[91]，正在积极努力将特定于云提供商的代码移到 Kubernetes 核心代码之外（从树内到树外）。

此增强功能为对控制平面可用性有严格要求的集群建立了迁移过程。

#3077^[92]上下文日志记录

阶段： Alpha
功能组：仪器
功能门： StructuredLogging
默认值: false

klog此增强功能是消除对 Kubernetes 日志库及其限制的持续努力的另一部分。它建立在 Kubernetes 1.19 结构化日志记录工作之上。

上下文日志记录包括针对开发人员的两项更改：

• 反转依赖关系，因此库不再使用 global Logger，而是传递给它们的实例。
• 库可以使用WithValues和WithName函数向记录器（和日志输出）添加额外的上下文信息。

例如，可以使用以下命令创建新的记录器WithName：

 logger := klog.FromContext(ctx).WithName("foo")

当这个记录器被传递和使用时：

   logger.Info("Done")

它将"foo"作为前缀包含在内。

一个相关的用例是单元测试，开发人员可以为每个测试用例提供自己的记录器来区分它们的输出。现在，这可以在不更改库代码的情况下完成。

此外，这种依赖倒置为消除对 klog 的依赖铺平了道路。全局记录器可以被logr.Logger.

#3031^[93]签署发布工件

阶段： Alpha
功能组：发布
功能门： N/A

为了帮助避免供应链攻击^[94]，最终用户应该能够验证下载资源的完整性，例如 Kubernetes 二进制文件。

此增强功能引入了一种统一的方式来对工件进行签名。它依赖于sigstore^[95]项目工具，更具体地说是cosign^[96]。虽然它没有添加新功能，但它肯定会帮助我们的集群得到更多保护。

此外，建议还实施其他措施来避免风险，例如未经授权访问签名密钥或其基础设施。例如，使用无密钥签名公开审核密钥使用情况。

#2578^[97] Windows 可使用 readiness 定义和工具集成

阶段： Alpha
功能组： windows
功能门： N/A

自 Kubernetes 1.14 以来^[98]，Windows 容器编排已准备好供企业采用。但是，一致性测试在 Windows 中并不像在 Linux 中那样可靠。

因此，为了评估 Windows Kubernetes 集群的运营准备情况，将开发涵盖以下领域的特定测试：

• 基本网络
• 基本服务帐户和本地存储
• 基本调度
• 基本并发功能
• Windows HostProcess 操作准备情况
• 活动目录
• 网络策略
• Windows 高级网络和服务代理
• Windows 工作器配置

这将为您提供操作工具，例如：

• 验证我们在 Kubernetes 中依赖的功能是否受特定 Windows Kubernetes 集群的支持。
• 评估 Windows 集群的 Kubernetes 支持矩阵的完整性。
• 了解我们当前版本的 Kubernetes 是否支持特定的 Windows 功能。

在 Windows 环境中为 Kubernetes 创建一个稳定的生态系统的努力正在为所有这些组织创造新的机会，这些组织的应用程序是特定于 Windows 的。容器不再是 Linux 独有的。

#2802^[99] 权威地识别 API 准入级别的 Windows pod

阶段：毕业到 Beta
功能组： windows
功能门： IdentifyPodOS
默认值： true

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

这是Kubernetes 1.24的全部内容，更详细内容请看：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#changelog-since-v1230

如果您打算使用这些特性中的任何一个，请准备升级您的集群。

翻译

https://sysdig.com/blog/kubernetes-1-24-whats-new/

参考资料