时间戳

首页 > 解决方案 > Kubernetes - 如果您不设置 pod CPU 请求或限制会发生什么？

kubernetes - Kubernetes - 如果您不设置 pod CPU 请求或限制会发生什么？

问题描述

我了解在Kubernetes pod 上为两者和/或资源设置 arequest或 a的概念，但我试图了解如果您不设置任何一个或不设置CPU 会发生什么？limitCPUmemoryrequestlimit

我们已经配置了一个 NGINX pod，但它request的. 我假设它至少有，并且会根据需要为该 pod 提供尽可能多的毫核，并且在节点上可用。如果节点用尽了所有可用的内核，那么它​​会停留在 1 毫内核吗？limitCPU1 millicore

标签： kubernetes

解决方案

如果您没有为 CPU 设置请求或限制，会发生什么？

当您没有指定 CPU 请求时，您是在说您不关心容器中运行的进程分配了多少 CPU 时间。

在最坏的情况下，它可能根本得不到任何 CPU 时间（当 CPU 上存在其他进程的大量需求时会发生这种情况）。尽管这对于时间要求不高的低优先级批处理作业可能很好，但显然不适合处理用户请求的容器。

您还请求1 millicore容器的内存。通过这样做，您说您希望在容器内运行的进程最多使用N mebibytesRAM。他们可能会使用更少，但您不会期望他们在正常情况下使用更多。

了解资源请求如何影响调度

通过指定资源请求，您可以指定 pod 所需的最小资源量。此信息是调度程序在将 pod 调度到节点时使用的信息。

每个节点都有一定数量的 CPU 和内存，可以分配给 pod。在调度 Pod 时，Scheduler 只会考虑具有足够未分配资源的节点来满足 Pod 的资源需求。

如果未分配的 CPU 或内存量小于 pod 请求的量，Kubernetes 不会将 pod 调度到该节点，因为节点无法提供 pod 所需的最小量。

了解如果超出限制会发生什么

带 CPU

CPU 是一种可压缩资源，进程在不等待 I/O 操作时想要消耗所有 CPU 时间是很自然的。

进程的 CPU 使用率受到限制，因此当为容器设置 CPU 限制时，不会为进程分配比配置限制更多的 CPU 时间。

有记忆

有了记忆，就不一样了。当一个进程试图分配超过其限制的内存时，该进程被杀死（据说容器是OOMKilled，其中OOM代表 Out Of Memory）。如果 pod 的重启策略设置为 Always 或OnFailure，则进程会立即重启，因此您甚至可能不会注意到它被终止。但是，如果它继续超过内存限制并被杀死，Kubernetes 将开始重新启动它，并且重新启动之间的延迟会增加。在这种情况下，您会看到一个CrashLoopBackOff状态。

kubectl get po
NAME        READY     STATUS             RESTARTS   AGE
memoryhog    0/1   CrashLoopBackOff         3       1m

注意：该CrashLoopBackOff状态并不意味着 Kubelet 已经放弃。这意味着每次崩溃后，Kubelet 都会增加重新启动容器之前的时间段。

了解检查容器崩溃的原因

kubectl describe pod
Name:
...
Containers:
main: ...
    State: Terminated
      Reason: OOMKilled
...

注意 Reason 属性OOMKilled。当前容器因内存不足 (OOM) 而被杀死。

推荐阅读