Kubernetes memory 限制：在同一个 pod 上有和没有 memory 限制的容器

Question

我的 pod 有两个容器（ PodA ）

第一个容器 ( C1 ) 具有以下限制

Limits:                                                                                                                                                                                                
  cpu:     2                                                                                                                                                                                           
  memory:  1Gi                                                                                                                                                                                         Requests:                                                                                        
  cpu:     100m                                                                                  
  memory:  128Mi

第二个容器 ( C2 ) 没有指定请求/限制

我有以下问题

1. 从我使用kubectl describe nodes可以看出， PodA的内存/cpu 请求/限制与C1中的相同。 那是对的吗？
2. C2的内存/cpu 限制是多少？ 是无界的吗？ 受限于PodA的限制（例如C1的限制）？
3. #2 的跟进 -> 如果C2要求的 memory 超过 1Gi，会发生什么？ 容器会不会用完memory，导致整个pod崩溃？ 或者只要节点有空闲的memory，就可以抢到更多的memory？

我试图用谷歌搜索，但我看到的所有示例都为两个容器设置了资源限制

Answer 1

Kubernetes 根据您是否添加了请求和限制将您的 Pod 置于服务质量类中。

如果 pod 中的所有容器都设置了限制，则 pod 属于Guaranteed class。

如果 pod 中的至少一个容器设置了请求（或限制），则该 pod 属于Burstable class。

如果没有为所有容器设置请求或限制，则 Pod 将属于Best Effort class。

在您的示例中，您的 pod 属于Burstable class 因为C2没有设置限制。

---

这些请求和限制用于两种情况 - 调度和资源耗尽。

调度

在调度过程中，根据可用资源考虑对 select 节点的请求。 limits可能会被过度使用，并且不会被考虑用于调度决策。

资源枯竭

您可以在两个资源上指定请求和限制 - cpu 和 memory

CPU 是一种可压缩资源，即 kernel 可以根据需要通过分配更少的 CPU 时间来限制进程的 CPU 使用率。 因此，如果其他进程处于空闲状态，则允许一个进程使用尽可能多的 CPU。 如果另一个进程需要 cpu，操作系统可以为使用更多 CPU 的进程限制 cpu 时间。 未使用的 cpu 时间将按其请求的比例进行分配。 如果您不希望这种无限 cpu 使用的行为，即您希望您的容器不超过某个阈值，您可以设置限制。

Memory 不是可压缩资源。 一旦分配给一个进程，kernel 就无法重新获得 memory。 因此，如果设置了限制，如果进程尝试使用超过限制，则会被 OOM 杀死。 如果没有设置限制，进程可以根据需要分配任意数量，但如果 memory 耗尽，重新获得一些空闲 memory 的唯一方法是终止进程。 这就是 QoS class 出现的地方。 BestEffort容器将是第一个被 OOM 杀死的容器。 下一个Burstable class 容器将在任何Guaranteed class 容器被杀死之前被杀死。 在容器具有相同 QoS class 的情况下，与其请求相比，使用更高百分比的 memory 的容器将被 OOM 杀死。

---

从我通过 kubectl describe 节点看到的情况来看，PodA 的内存/cpu 请求/限制与 C1 中的相同。 那是对的吗？

是的

C2 的内存/cpu 限制是多少？ 是无界的吗？ 受限于 PodA 的限制（例如 C1 的限制）？

CPU 作为可压缩资源对于所有容器都是无限制的（如果指定了限制，则可以达到限制）。 当具有请求集的其他容器需要更多 cpu 时间时，C2 将受到限制。

#2 的跟进 -> 如果 C2 要求的 memory 超过 1Gi，会发生什么？ 容器会不会用完memory，导致整个pod崩溃？ 或者只要节点有空闲的memory，就可以抢到更多的memory？

它可以抓取尽可能多的 memory。 但是如果节点没有更多的空闲 memory 可以分配给其他进程，它将是第一个被 OOM 杀死的节点。