Kubernetes 内存限制：同一 pod 上有和没有内存限制的容器
Kubernetes memory limit : Containers with and without memory limit on same pod
我的 pod 中有两个容器 (PodA)
第一个容器 (C1) 具有以下限制
Limits:
cpu: 2
memory: 1Gi Requests:
cpu: 100m
memory: 128Mi
第二个容器 (C2) 未指定 requests/limits
我有以下问题
- 据我所见
kubectl describe nodes，PodA 的 memory/cpu request/limits 与 C1 的相同。对吗？
C2 的 memory/cpu 限制是多少？它是无界的吗？限于PodA的限制（例如C1的限制）？- #2 的跟进 -> 如果
C2 要求超过 1Gi 的内存会怎样？容器 运行 会不会内存不足，导致整个 pod 崩溃？还是只要节点有空闲内存，它就可以获取更多内存？
我尝试 google，但我看到的所有示例都为两个容器设置了资源限制
Kubernetes 根据您是否添加了请求和限制，将您的 pods 放入 Quality Of Service classes。
如果 pods 中的所有容器都设置了限制，则 pod 属于 Guaranteed class。
如果 pod 中至少有一个容器设置了请求（或限制），则 pod 属于 Burstable class.
如果没有为所有容器设置请求或限制，pods 属于 Best Effort class。
在您的示例中，您的广告连播属于 Burstable class，因为 C2 没有设置限制。
这些请求和限制用于两种情况 - 调度和资源耗尽。
计划
在调度期间，根据可用资源将请求考虑到 select 节点。 limits 可能会过度使用，并且不会被考虑用于调度决策。
资源枯竭
有两种资源可以在其上本地指定请求和限制 - cpu 和内存
CPU 是一种可压缩资源，即如果需要，内核可以通过分配更少的 CPU 时间来限制 cpu 进程的使用。因此，如果其他进程空闲，则允许进程使用尽可能多的 CPU 。如果另一个进程需要 cpu，OS 可以限制使用更多 CPU 的进程的 cpu 时间。未使用的 cpu 时间将按他们的请求比例进行分配。如果您不希望这种无限制 cpu 使用行为，即您希望您的容器不超过特定阈值，您可以设置限制。
内存不是可压缩的资源。一旦分配给进程，内核就无法重新获得内存。因此，如果设置了限制，如果进程尝试使用超过限制的数量，它就会被 OOM 杀死。如果没有设置限制，进程可以随心所欲地分配内存，但如果内存耗尽，重新获得一些可用内存的唯一方法是终止进程。这就是 QoS class 发挥作用的地方。 BestEffort class 容器将是第一个被 OOM 杀死的容器。接下来 Burstable class 个容器将在任何 Guaranteed class 个容器被杀死之前被杀死。在容器具有相同 QoS class 的情况下，与其请求相比使用更高百分比内存的容器将被 OOM 终止。
From what I can see with a kubectl describe nodes, the memory/cpu request/limits for the PodA are the same as the one from C1. Is that correct?
是
What are the memory/cpu limits for C2? Is it unbounded? Limited to the limits of PodA (e.g. limits of C1)?
CPU 作为可压缩资源对于所有容器都是无限制的（如果指定了限制，则达到限制）。当设置了请求的其他容器需要更多 cpu 时间时，C2 将受到限制。
Follow up of #2 -> What happens if C2 asks for more than 1Gi of memory? Will the container run out of memory, and cause the whole pod to crash? Or will it be able to grab more memory, as long as the node has free memory?
它可以随心所欲地获取内存。但是如果节点没有更多的可用内存分配给其他进程，它将是第一个被 OOM 杀死的。
我的 pod 中有两个容器 (PodA)
第一个容器 (C1) 具有以下限制
Limits:
cpu: 2
memory: 1Gi Requests:
cpu: 100m
memory: 128Mi
第二个容器 (C2) 未指定 requests/limits
我有以下问题
- 据我所见
kubectl describe nodes，PodA的 memory/cpu request/limits 与C1的相同。对吗？ C2的 memory/cpu 限制是多少？它是无界的吗？限于PodA的限制（例如C1的限制）？- #2 的跟进 -> 如果
C2要求超过 1Gi 的内存会怎样？容器 运行 会不会内存不足，导致整个 pod 崩溃？还是只要节点有空闲内存，它就可以获取更多内存？
我尝试 google，但我看到的所有示例都为两个容器设置了资源限制
Kubernetes 根据您是否添加了请求和限制，将您的 pods 放入 Quality Of Service classes。
如果 pods 中的所有容器都设置了限制，则 pod 属于 Guaranteed class。
如果 pod 中至少有一个容器设置了请求（或限制），则 pod 属于 Burstable class.
如果没有为所有容器设置请求或限制，pods 属于 Best Effort class。
在您的示例中，您的广告连播属于 Burstable class，因为 C2 没有设置限制。
这些请求和限制用于两种情况 - 调度和资源耗尽。
计划
在调度期间，根据可用资源将请求考虑到 select 节点。 limits 可能会过度使用，并且不会被考虑用于调度决策。
资源枯竭
有两种资源可以在其上本地指定请求和限制 - cpu 和内存
CPU 是一种可压缩资源，即如果需要，内核可以通过分配更少的 CPU 时间来限制 cpu 进程的使用。因此，如果其他进程空闲，则允许进程使用尽可能多的 CPU 。如果另一个进程需要 cpu，OS 可以限制使用更多 CPU 的进程的 cpu 时间。未使用的 cpu 时间将按他们的请求比例进行分配。如果您不希望这种无限制 cpu 使用行为，即您希望您的容器不超过特定阈值，您可以设置限制。
内存不是可压缩的资源。一旦分配给进程，内核就无法重新获得内存。因此，如果设置了限制，如果进程尝试使用超过限制的数量，它就会被 OOM 杀死。如果没有设置限制，进程可以随心所欲地分配内存，但如果内存耗尽，重新获得一些可用内存的唯一方法是终止进程。这就是 QoS class 发挥作用的地方。 BestEffort class 容器将是第一个被 OOM 杀死的容器。接下来 Burstable class 个容器将在任何 Guaranteed class 个容器被杀死之前被杀死。在容器具有相同 QoS class 的情况下，与其请求相比使用更高百分比内存的容器将被 OOM 终止。
From what I can see with a kubectl describe nodes, the memory/cpu request/limits for the PodA are the same as the one from C1. Is that correct?
是
What are the memory/cpu limits for C2? Is it unbounded? Limited to the limits of PodA (e.g. limits of C1)?
CPU 作为可压缩资源对于所有容器都是无限制的（如果指定了限制，则达到限制）。当设置了请求的其他容器需要更多 cpu 时间时，C2 将受到限制。
Follow up of #2 -> What happens if C2 asks for more than 1Gi of memory? Will the container run out of memory, and cause the whole pod to crash? Or will it be able to grab more memory, as long as the node has free memory?
它可以随心所欲地获取内存。但是如果节点没有更多的可用内存分配给其他进程，它将是第一个被 OOM 杀死的。