Kubernetes - 如果不设置 pod CPU 请求或限制会怎样？

Question

我理解设置 request 的概念或 limit在 Kubernetes pod 上为两者 CPU和/或 memory资源，但我试图了解如果您不设置会发生什么 request或 limit说一个CPU？
我们已经配置了一个 NGINX pod，但它没有 request或 limit为其设置 CPU .我假设它至少会有 1 millicore并将根据需要为该 pod 提供尽可能多的毫核，并在节点上可用。如果节点已经耗尽了所有可用的内核，那么它​​是否只是停留在 1 毫核上？

Answer 1

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

When you don’t specify a request for CPU, you’re saying you don’tcare how much CPU time the process running in your container isallotted.

In the worst case, it may not get any CPU time at all (this happenswhen a heavy demand by other processes exists on the CPU). Althoughthis may be fine for low-priority batch jobs, which aren’ttime-critical, it obviously isn’t appropriate for containers handlinguser requests.

you’re also requesting 1 millicore of memory for the container. Bydoing that, you’re saying that you expect the processes runninginside the container to use at most N mebibytes of RAM. Theymight use less, but you’re not expecting them to use more than thatin normal circumstances.

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

By specifying resource requests, you’re specifying the minimum amount of resources your pod needs. This information is what the Scheduler uses when scheduling the pod to a node.

Each node has a certain amount of CPU and memory it can allocate to pods. When scheduling a pod, the Scheduler will only consider nodes with enough unallocated resources to meet the pod’s resource requirements.

If the amount of unallocated CPU or memory is less than what the pod requests, Kubernetes will not schedule the pod to that node, because the node can’t provide the minimum amount required by the pod.

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

CPU is a compressible resource, and it’s only natural for a process to want to consume all of the CPU time when not waiting for an I/O operation.

a process’ CPU usage is throttled, so when a CPU limit is set for a container, the process isn’t given more CPU time than the configured limit.

带内存

With memory, it’s different. When a process tries to allocate memory over its limit, the process is killed (it’s said the container is OOMKilled, where OOM stands for Out Of Memory).If the pod’s restart policy is set to Always or OnFailure, the process is restarted immediately, so you may not even notice it getting killed. But if it keeps going over the memory limit and getting killed, Kubernetes will begin restarting it with increasing delays between restarts. You’ll see a CrashLoopBackOff status in that case.

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
...

Pay attention to the Reason attribute OOMKilled. The current container was killed because it was out of memory (OOM).