k8s 1.27 新特性(Pod无需重启调整CPU内存资源...)

1 简介

太平洋时间 2023 年 4 月 11 日，Kubernetes 1.27 正式发布。此版本距离上版本发布时隔 4 个月，是 2023 年的第一个版本。

新版本中 release 团队跟踪了 60 个 enhancements，比之前版本都要多得多。 其中 13 个功能升级为稳定版，29 个已有功能进行优化升级为 Beta，另有 18 个 Alpha 级别的功能， 大多数为全新功能。本版本包含了很多重要功能以及用户体验优化 ，本文会在下一小节进行部分重要功能的详细介绍。

2 重要功能

2.1 镜像仓库从 k8s.gcr.io 切换到 registry.gcr.io

自 Kubernetes 1.25 版本起，Kubernetes 容器镜像仓库域名已经从 k8s.gcr.io 更改为 registry.k8s.io。 2023 年 3 月 20 日之后，k8s.gcr.io 将不再继续直接维护，而是被代理到 registry.k8s.io。

2.2 KEP-1847：StatefulSet PVC 自动删除功能特性 Beta

在 v1.23 中引入的 StatefulSetAutoDeletePVC 功能将在 1.27 版本中升级为 Beta，并默认开启。 然而，默认开启并不意味着所有 StatefulSet 的 PVC 都将自动删除。

用户可以配置 whenDeleted 或 whenScaled 阶段以触发 Retain 或 Delete 行为。 其中，Retain 是默认行为，只有配置了 Delete 策略的 StatefulSet 在被删除时才会触发对应的 PVC 删除动作。

2.3 KEP-3453：优化大型集群中 kube-proxy 的 iptables 模式性能

功能 MinimizeIPTablesRestore 在 1.26 版本中引入，并在 1.27 版本中升级为 Beta 并默认启用。 该功能旨在改善大型集群中 kube-proxy 的 iptables 模式性能。

如果您遇到 Service 信息未正确同步到 iptables 的问题，您可以通过将 kube-proxy 启动参数设置为 --feature-gates=MinimizeIPTablesRestore=false 来禁用该功能（并向社区提交问题）。 您还可以查看 kube-proxy 的 metrics 信息中的 sync_proxy_rules_iptables_partial_restore_failures_total 指标来监控规则同步失败的次数。

2.4 KEP-2831 和 KEP-647：APIServer 和 Kubelet 的 Tracing 功能 Beta

APIServerTracing 已升级为 Beta 状态，并默认启用。 目前仅支持 kube-apiserver 和 etcd 组件的 Tracing，但未来会添加对 client-go 的支持。 其他组件也将逐步添加 Tracing 能力。kube-apiserver 中的 Tracing 需要指定配置文件才能启用，并且必须指定接收端。

Kubelet 和容器运行时通过 CRI 调用的 Tracing 也已经默认开启。 类似地， kubelet 的 KubeletTracing 功能已经默认开启，但是需要配置 Tracing 的接收端才能正常工作。

2.5 KEP-3077：上下文日志

上下文日志可以帮助用户理解日志的上下文信息，更好地让日志帮助用户排错和理解，提升日志的可观测性。 目前 kube-controller-manager 的迁移工作已经完成，kube-scheduler 的迁移工作将在 1.28 版本中完成。

2.6 KEP-1287：Pod 资源的原地纵向弹性伸缩

Kubernetes 现已支持原地调整 Pod 资源大小， 容器组重建不再是必须的，这很大程度上缓解了横向弹性的冷启动等问题。

• 在之前的版本中，Pod API 不支持修改资源。也就是说，容器定义的资源限制和请求（如 CPU 和内存）是不可变的。 在 1.25 版本中，CRI API 开始支持 Pod 资源限制的热更新。

允许用户在不重启容器的情况下调整分配给 Pod 的 CPU 或 memory 资源的大小。为了实现这一点，pod container 中的 resources 字段现在允许对 cpu 和 memory 资源进行更改。可以通过 patch 修改正在运行的 pod spec 来实现。

这也意味着 pod.spec 中 resources 字段不能再作为 pod 实际资源的指标。监控工具和其他此类应用程序现在必须查看 pod status 中的新字段。Kubernetes 通过 CRI（容器运行时接口）API 调用运行时（例如负责运行容器的 containerd）来查询实际的 request CPU 和 memory 和 limit。来自容器运行时的响应反映在 pod 的 status 中。

此外，还添加了一个 restartPolicy 字段，它使用户可以控制：在调整资源大小时如何处理容器。

• 在 Pod 的容器中添加了 resizePolicy 字段，以允许用户控制容器在资源变更时是否重启。
• 在容器状态中添加了 allocatedResources 字段，用于描述为 Pod 分配的节点资源。
• 在容器状态中添加了 resources 字段，用于报告应用于正在运行的容器的实际资源。
• 在 Pod 状态中添加了 resize 字段，用于描述请求调整 Pod 大小的状态。该字段可以是 Proposed（已提出）， InProgress（进行中），Deferred（已延迟）或 Infeasible（不可行）。

Proposed值是对请求的调整大小的确认，并指示该请求已被验证和记录。

InProgress值表示节点已接受调整大小请求，并且正在将调整大小请求应用于 pod 的容器。

Deferred值为表示此时无法授予请求的调整大小，节点将不断重试。当其他 pod 离开并释放节点资源时，可以授予调整大小。

Infeasible的值是一个信号，表明该节点无法适应请求的调整大小。如果请求的调整大小超过节点可以为 pod 分配的最大资源，就会发生这种情况。

2.6.1 何时使用此功能

Pod 在节点上运行，但资源过多或过少。

Pod 没有被调度是因为集群中没有足够的 CPU 或内存，而集群中运行的 Pod 被过度配置而未得到充分利用。

驱逐那些需要更多资源以将它们调度到更大节点上的有状态 pod，是一项昂贵或破坏性的操作，可以缩小或移动节点中优先级较低的 pod 。

用例:

基于云的开发环境

在这种情况下，开发人员或开发团队在本地编写代码，但在 Kubernetes pod 中使用反映生产使用的一致配置构建和测试代码。当开发人员编写代码时，此类 pod 需要的资源最少，但当他们构建代码或运行一系列测试时，则需要更多的 CPU 和内存。这个用例可以利用就地 pod 调整大小功能（在 eBPF 的帮助下）快速调整 pod 的资源大小并避免内核 OOM（内存不足）killer 终止进程。

Java 进程初始化 CPU 要求

某些 Java 应用程序在初始化期间可能需要比正常进程操作期间所需的 CPU 多得多的 CPU。如果此类应用程序指定适合正常操作的 CPU 请求和限制，则它们可能会遇到非常长的启动时间。这样的 pod 可以在创建 pod 时请求更高的 CPU 值，并且可以在应用程序完成初始化后调整大小以满足正常运行需要即可。

2.6.2 如何使用此功能

为了在 v1.27 中使用此功能，必须启用 InPlacePodVerticalScaling 功能门。可以启动一个启用了此功能的本地集群，如下所示：

root@vbuild:~/go/src/k8s.io/kubernetes# FEATURE_GATES=InPlacePodVerticalScaling=true ./hack/local-up-cluster.sh
go version go1.20.2 linux/arm64
+++ [0320 13:52:02] Building go targets for linux/arm64
    k8s.io/kubernetes/cmd/kubectl (static)
    k8s.io/kubernetes/cmd/kube-apiserver (static)
    k8s.io/kubernetes/cmd/kube-controller-manager (static)
    k8s.io/kubernetes/cmd/cloud-controller-manager (non-static)
    k8s.io/kubernetes/cmd/kubelet (non-static)
...
...
Logs:
  /tmp/etcd.log
  /tmp/kube-apiserver.log
  /tmp/kube-controller-manager.log

  /tmp/kube-proxy.log
  /tmp/kube-scheduler.log
  /tmp/kubelet.log

To start using your cluster, you can open up another terminal/tab and run:

  export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
  cluster/kubectl.sh

Alternatively, you can write to the default kubeconfig:

  export KUBERNETES_PROVIDER=local

  cluster/kubectl.sh config set-cluster local --server=https://localhost:6443 --certificate-authority=/var/run/kubernetes/server-ca.crt
  cluster/kubectl.sh config set-credentials myself --client-key=/var/run/kubernetes/client-admin.key --client-certificate=/var/run/kubernetes/client-admin.crt
  cluster/kubectl.sh config set-context local --cluster=local --user=myself
  cluster/kubectl.sh config use-context local
  cluster/kubectl.sh

一旦本地集群启动并运行，Kubernetes 用户就可以使用资源调度 pod，并通过 kubectl 调整 pod 的资源大小.

2.6.3 已知问题

在 v1.27 中 此功能处于 alpha 阶段。以下是用户可能会遇到的一些已知问题：

containerd v1.6.9 以下的版本没有此功能的完整端到端操作所需的 CRI 支持。尝试调整 pod 的大小似乎会停留在InProgress状态，并且 pod 状态中的 resources 字段永远不会更新，即使新资源可能已经在正在运行的容器上生效。

Pod resize 可能会遇到与其他 pod 更新的竞争条件，从而导致延迟执行 pod resize。

在 Pod 的状态中反映调整大小的容器资源可能需要一段时间。

此功能不支持静态 CPU 管理策略。

2.7 KEP-3386：Kubelet 事件驱动 PLEG 升级为 Beta

在节点 Pod 较多的情况下，通过容器运行时的 Event 驱动 Pod 状态更新，能够有效地提升效率。 在 1.27 中，该功能已经达到了 Beta 条件，基础的 E2E 测试任务已经添加。 之所以默认关闭该功能，是因为社区认为该功能还需要补充以下验证：压力测试、恢复测试和带退避逻辑的重试。

压力测试需要在单个 Pod 中创建大量容器以生成 CRI 事件，并观察 latency 值是否超过 1 秒。

恢复测试则是为了验证 Kubelet 在重新启动后能否正确地更新容器状态。

而带退避逻辑的重试则是为了解决 CRI Runtime 宕机时 Kubelet 可能无法连接的问题。

2.8 KEP-3476：Volume Group 快照 Alpha（API）

能够在 Pod 的所有卷上同一时间快照，将成为容灾备份和故障恢复场景的重大技术突破。 现在，您不必担心应用程序因备份的卷存在几秒钟差异而无法正确运行。 此外，在安全研究方面，存储卷的组快照功能也将是一个重大变革。 排查问题时，您的快照和 Pod 的状态是可对照的。 需要注意的是该功能并非在 Kubernetes 仓库，VolumeGroupSnapshots API 的定义目前维护在 https://github.com/kubernetes-csi/external-snapshotter

2.9 KEP-3838 和 KEP-3521：Pod 调度就绪态功能增强

调度就绪态功能 PodSchedulingReadiness，在 v1.26 作为 Alpha 功能引入，从 v1.27 开始该功能升级为 Beta，默认开启。

该功能在 Pod 对象中引入了 .spec.schedulingGates 字段，用来定义 Pod 是否允许开始调度。 此功能最常见的一个场景是：批量调度，一组 Pod 需要等待集群资源满足整组 Pod 同时启动，才能开始调度。

针对受 SchedulingGate 限制悬停（Gated）状态的 Pod，为了让第三方控制器更灵活地控制这些 Pod 的最终调度策略， 新版本中允许 Gated Pod 的 NodeAffinity 和 NodeSelector 可以被修改，但仅允许缩小节点范围。 缩小范围是指支持添加新策略，不能删除或者修改已有策略。

2.10 KEP-3243：Deployment 滚动更新过程中的调度优化

PodTopologySpread 调度策略之前只关注标签的键，而不关注标签的值，因此在滚动更新 Deployment 时， 调度无法区分新旧实例，进而导致可能新实例调度不均匀。例如，滚动更新的最后一组 4 个旧 Pod 都在同一个节点， 那么新 Pod 调度为了更加均匀分布，大概率会调度到其他节点；滚动最后删除这一组旧 Pod 后，有可能一个节点没有调度该 Deployment。

在 v1.27 中，PodTopologySpread 调度策略可以区分调度 Pod 标签的值 （这里通常指 Pod 的 pod-template-hash 标签，不同 replica set 对应的 Pod 该标签的值不同）， 这样滚动更新后，新的 Pod 实例会被调度得更加均匀 。

x-kubernetes-validations:
- rule: "self.x <= self.maxLimit"
  messageExpression: '"x exceeded max limit of " + string(self.maxLimit)'

2.11 KEP-2258：节点日志查询

v1.27 添加了 NodeLogQuery 特性门控 (Feature Gate)， 为集群管理员提供了使用 kubectl 流式查看节点日志的功能，无需登录节点。 该功能目前是 Alpha，需要配置 kubelet 开启特性门控，同时还需要设置 enableSystemLogHandler 和 enableSystemLogQuery 为 true。在 Linux 上， 我们假设系统服务日志可以通过 journald 获得。在 Windows 上， 我们假设系统服务日志可以在应用程序日志提供程序中获得。在这两个操作系统中， 还可以通过读取 /var/log/ 目录下的文件来获取日志。此功能对 Windows 的支持也在逐步完善， 目前使用 Get-WinEvent 来获取系统和应用程序日志。

不仅如此，目前节点日志获取功能还支持了一些参数。其中 query 表示服务名， 可指定 kubelet、containerd 等。patern 通过提供的 PERL 兼容正则表达式过滤日志条目。 此外支持的参数还有 sinceTime、untilTime、tailLines、boot。

# Fetch kubelet logs from a node named node-1.example that have the word "error"
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"

2.12 KEP-3659：kubectl apply –prune 重新设计

--prune 在 v1.5 就作为 Alpha 功能引入，提供了自动清理 apply yaml 删除的部分对象， 但是这个过程有些性能问题和缺陷，在一些情况下会造成对象泄漏。常见原因包括 allowlist （之前叫 whitelist）GVK 内容和 apply 内容不匹配，或者命名空间变化。命名空间操作变化的案例， 比如第一次 apply 操作了命名空间 A 和 B；而第二次 apply 如果只 apply 命名空间 A 的资源，那么命名空间 B 的资源将不会被清理。

在 v1.27 中，kubectl 对 apply --prune 的功能进行了重新的设计，增加了 --applyset 配合使用，目前该功能仍然是 Alpha 级别 ， 因此需要配置 KUBECTL_APPLYSET 环境变量为 1 或者 true，才能启用。在 kubectl apply 时，kubectl 会给对象添加 applyset.kubernetes.io/part-of 标签，在清理时会使用该标签。而为了满足更复杂的场景，还引入了 applyset.kubernetes.io/id 来标识 Parent 对象，以及 toolling、additional-namespaces 来帮助区分对象和增加命名空间信息等，更多详情请阅读 KEP 内容。

3 升级注意事项

本节主要介绍 v1.27 中 API 变化，以及功能的移除以及废弃，废弃的功能通常会在 1-2 个版本之后移除。 更多详情请查看 Kubernetes 在 v1.27 中移除的特性和主要变更。

Kubernetes 在 v1.27 中移除的特性和主要变更：https://kubernetes.io/zh-cn/blog/2023/03/17/upcoming-changes-in-kubernetes-v1-27/

其中 需要重点关注的，IPv6DualStack 外部云供应商特性门控已被删除。 （该功能在 1.23 版本中成为 GA，几个版本之前已删除所有其他组件的特性门控。）如果您仍然手动启用它，则必须立即停止。

k8s.gcr.io 重定向到 registry.k8s.io 相关说明

再次强调，Kubernetes 项目为了托管其容器镜像，使用社区拥有的一个名为 registry.k8s.io. 的镜像仓库。 从 3 月 20 日起，所有来自过期 k8s.gcr.io 仓库的流量将被重定向到 registry.k8s.io。已弃用的 k8s.gcr.io 仓库未来最终将被关停。

其他需要注意的变化¶

CSIStorageCapacity 的 storage.k8s.io/v1beta1 API 版本在 v1.24 中已被弃用，将在 v1.27 中被移除。

移除 NetworkPolicyEndPort、LocalStorageCapacityIsolation、StatefulSetMinReadySeconds、 IdentifyPodOS、DaemonSetUpdateSurge、EphemeralContainers、CSIInlineVolume、CSIMigration、ControllerManagerLeaderMigration 特性门控，这些特性大部分都是在 v1.25 之前的版本正式 GA。

kube-apiserver 移除了 --master-service-namespace 命令行参数。

kube-controller-manager 命令行参数 --enable-taint-manager 和 --pod-eviction-timeout 被移除。

kubelet 移除了命令行参数 --container-runtime，该参数目前只有一个可选值 "remote" 并在之前版本中废弃。

弃用了 Alpha 状态的 seccomp 注解 seccomp.security.Alpha.kubernetes.io/pod 和 container.seccomp.security.Alpha.kubernetes.io。

SecurityContextDeny 特性门控已经废弃，将在未来版本移除。

由于使用 golang 1.20.2 构建时遇到问题，Linux/arm 将不会在 Kubernetes 1.27 中发布。注意， arm64 仍然支持。

https://docs.daocloud.io/blogs/230412-k8s-1.27/#_5