kubernetes [FG:InPlacePodVerticalScaling] 当仅配置内存请求时，显示最小CPU请求

8gsdolmq 于 3个月前发布在 Kubernetes

关注(0)|答案(6)|浏览(45)

发生了什么？
如果 InPlacePodVerticalScaling 功能被启用，并且在pod中仅配置了内存资源请求，那么pod状态中将显示内部设置的最小CPU请求：

$ kubectl get pod testpod -o jsonpath='spec: {.spec.containers[0].resources}{"\nallocatedResources: "}{.status.containerStatuses[0].allocatedResources}{"\nstatus: "}{.status.containerStatuses[0].resources}{"\n"}'
spec: {"requests":{"memory":"200Mi"}}
allocatedResources: {"memory":"200Mi"}
status: {"requests":{"cpu":"2m","memory":"200Mi"}}

你预期会发生什么？
最小CPU请求不会显示在pod状态中。

我们如何尽可能精确地重现它？

启用 InPlacePodVerticalScaling 功能。
创建一个仅配置内存请求的pod:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  containers:
  - image: nginx
    name: testpod
    resources:
      requests:
        memory: 200Mi
  restartPolicy: Always

在pod状态中查看其资源：

$ kubectl get pod testpod -o jsonpath='spec: {.spec.containers[0].resources}{"\nallocatedResources: "}{.status.containerStatuses[0].allocatedResources}{"\nstatus: "}{.status.containerStatuses[0].resources}{"\n"}'
spec: {"requests":{"memory":"200Mi"}}
allocatedResources: {"memory":"200Mi"}
status: {"requests":{"cpu":"2m","memory":"200Mi"}}

我们需要了解其他信息吗？

无响应*

Kubernetes版本

$ kubectl version
Client Version: v1.30.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.0

云提供商
N/A

操作系统版本

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

安装工具
容器运行时(CRI)和版本(如适用)
相关插件(CNI,CSI,...)和版本(如适用)

kubernetes

来源：https://github.com/kubernetes/kubernetes/issues/126195

6条答案

按热度按时间

4urapxun1#

如果InPlacePodVerticalScaling被禁用，Pod状态中是否会显示内部设置的最低CPU请求？

赞(0）回复(0）举报 4个月前

q43xntqr2#

不，除非启用了InPlacePodVerticalScaling,否则容器资源不会显示在pod状态中。

赞(0）回复(0）举报 4个月前

wmomyfyw3#

在运行时状态中的最低CPU请求导致kubelet内部发生另一个错误。在kubelet.log的每个pod resync中记录以下消息：

Jul 30 09:14:47 kind-control-plane kubelet[702]: I0730 09:14:47.436195     702 kuberuntime_manager.go:1051] "computePodActions got for pod" podActions="KillPod: false, CreateSandbox: false, UpdatePodResources: false, Attempt: 0, InitContainersToStart: [], ContainersToStart: [], EphemeralContainersToStart: [],ContainersToUpdate: map[cpu:[{0 {containerd 34bd8427f9d86a8795ba5d56ddc5f51d7b3dd9722686c62d30c1e672d6910ca9} {314572800 209715200 0 0} 0xc0014c7e00}]], ContainersToKill: map[]" pod="default/resize-pod"
Jul 30 09:14:47 kind-control-plane kubelet[702]: E0730 09:14:47.436340     702 kuberuntime_manager.go:750] "podResources.CPUQuota or podResources.CPUShares is nil" pod="resize-pod"

由于未设置的pod规范中的CPU请求被视为零，而运行时状态中的CPU请求是最小值，因此由于差距计算出调整大小的操作：

kubernetes/pkg/kubelet/kuberuntime/kuberuntime_manager.go
第573行
| | desiredCPURequest:=container.Resources.Requests.Cpu().MilliValue() |
kubernetes/pkg/kubelet/kuberuntime/kuberuntime_manager.go
第586行
| | currentCPURequest=kubeContainerStatus.Resources.CPURequest.MilliValue() |
这是在#126388中描述的情况，其中当未配置CPU限制时调整CPU请求。然后，它遇到以下错误：

kubernetes/pkg/kubelet/kuberuntime/kuberuntime_manager.go
第754到758行
| | ifpodResources.CPUQuota==nil||podResources.CPUShares==nil { |
| | klog.ErrorS(nil, "podResources.CPUQuota or podResources.CPUShares is nil", "pod", pod.Name) |
| | result.Fail(fmt.Errorf("podResources.CPUQuota or podResources.CPUShares is nil for pod %s", pod.Name)) |
| | return |
| | } |

赞(0）回复(0）举报 4个月前

vq8itlhq4#

另外提到的问题(#126195 (comment))可能可以通过#120791修复。

赞(0）回复(0）举报 4个月前

v09wglhw5#

这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题，他们将通过应用triage/accepted标签并提供进一步的指导来接受它。
组织成员可以通过在评论中写入/triage accepted来添加triage/accepted标签。
有关使用PR评论与我互动的说明，请查看here。如果您对我的行为有任何问题或建议，请针对kubernetes-sigs/prow仓库提出一个问题。