如果您已经部署了指定 CPU 或 Memory 资源的 Kubernetes pod，可能已经注意到更改资源值涉及重新启动 pod。直到现在，这一直是运行工作负载的破坏性操作。
在 Kubernetes v1.27 中，添加了一个新的 alpha 功能，允许用户在不重启容器的情况下调整分配给 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 字段，它使用户可以控制：在调整资源大小时如何处理容器。
v1.27 有什么新内容？
除了在 Pod 的 spec 中添加调整大小策略外，还在 Pod 的 status 中添加了一个名为 allocatedResources 的新字段。containerStatuses该字段反映了分配给 Pod 容器的节点资源。
此外，一个名为resources的新字段已添加到容器的 status 中。该字段反映容器运行时报告的在运行容器上配置的实际资源 request 和 limit。
最后，一个名为resize的新字段已添加到 pod 的 status，以显示上次请求调整大小的状态。
Proposed值是对请求的调整大小的确认，并指示该请求已被验证和记录。InProgress值表示节点已接受调整大小请求，并且正在将调整大小请求应用于 pod 的容器。Deferred值为表示此时无法授予请求的调整大小，节点将不断重试。当其他 pod 离开并释放节点资源时，可以授予调整大小。Infeasible的值是一个信号，表明该节点无法适应请求的调整大小。如果请求的调整大小超过节点可以为 pod 分配的最大资源，就会发生这种情况。
何时使用此功能
以下是此功能可能有用的几个示例：
- Pod 在节点上运行，但资源过多或过少。
- Pod 没有被调度是因为集群中没有足够的 CPU 或内存，而集群中运行的 Pod 被过度配置而未得到充分利用。
- 驱逐那些需要更多资源以将它们调度到更大节点上的有状态 pod，是一项昂贵或破坏性的操作，可以缩小或移动节点中优先级较低的 pod 。
如何使用此功能
为了在 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 的资源大小。
用例
基于云的开发环境
在这种情况下，开发人员或开发团队在本地编写代码，但在 Kubernetes pod 中使用反映生产使用的一致配置构建和测试代码。当开发人员编写代码时，此类 pod 需要的资源最少，但当他们构建代码或运行一系列测试时，则需要更多的 CPU 和内存。这个用例可以利用就地 pod 调整大小功能（在 eBPF 的帮助下）快速调整 pod 的资源大小并避免内核 OOM（内存不足）killer 终止进程。
Java 进程初始化 CPU 要求
某些 Java 应用程序在初始化期间可能需要比正常进程操作期间所需的 CPU 多得多的 CPU。如果此类应用程序指定适合正常操作的 CPU 请求和限制，则它们可能会遇到非常长的启动时间。这样的 pod 可以在创建 pod 时请求更高的 CPU 值，并且可以在应用程序完成初始化后调整大小以满足正常运行需要即可。
已知的问题
在 v1.27 中 此功能处于 alpha 阶段。以下是用户可能会遇到的一些已知问题：
- containerd v1.6.9 以下的版本没有此功能的完整端到端操作所需的 CRI 支持。尝试调整 pod 的大小似乎会停留在
InProgress状态，并且 pod 状态中的resources字段永远不会更新，即使新资源可能已经在正在运行的容器上生效。 - Pod resize 可能会遇到与其他 pod 更新的竞争条件，从而导致延迟执行 pod resize。
- 在 Pod 的状态中反映调整大小的容器资源可能需要一段时间。
- 此功能不支持静态 CPU 管理策略。
- END -
