如果Kubernetes吊舱超过其cpu资源'；限制'；？

文件：

容器可能被允许或不被允许在较长时间内超过其CPU限制。但是，它不会因为CPU使用过多而被终止

---

容器将不允许使用超过其平均限制的CPU，其他容器将受到保护，防止CPU过度使用。

从头开始

创建Pod时，Kubernetes调度程序会选择一个节点供Pod运行。每个节点对于每种资源类型都有一个最大容量：它可以为POD提供的CPU和内存量。调度程序确保，对于每种资源类型，调度容器的资源请求之和小于节点的容量。请注意，尽管节点上的实际内存或CPU资源使用率非常低，但如果容量检查失败，调度程序仍然拒绝在节点上放置Pod。这可以防止在稍后资源使用率增加时（例如，在请求速率的每日峰值期间）节点上出现资源短缺

要指定容器的CPU请求，请在容器资源清单中包含资源：请求字段。要指定CPU限制，请包括资源：限制

CPU请求和限制与容器相关联，但将Pod视为具有CPU请求和限制是很有用的。Pod的CPU请求是Pod中所有容器的CPU请求之和。同样，Pod的CPU限制是Pod中所有容器的CPU限制之和

Pod调度基于请求。只有当节点有足够的可用CPU资源来满足Pod CPU请求时，Pod才会计划在节点上运行

在下面pod的配置文件中，容器请求100个CPU，这可能超过集群中任何节点的容量

NAME                      CPU(cores)   MEMORY(bytes)   
apache-757ddfbc75-khhfw   10m          61Mi

创建pod后，您将获得类似的输出：

这表明由于节点上的CPU资源不足，无法调度容器

总体文档：，。

k8s文档参考：

容器可能被允许或不被允许在较长时间内超过其CPU限制。但是，它不会因CPU过度使用而被杀死

---

在大多数情况下，什么都不会发生。CPU的使用非常灵活。

似乎出现了节流现象（官方文档中没有这样写）：

Kubernetes使用内核节流来实现CPU限制。如果应用程序超出限制，它就会受到限制（即更少的CPU周期）。另一方面，内存请求和限制的实现方式不同，更易于检测。您只需检查pod的上次重启状态是否为OOMKilled

---

如果一个容器试图超过指定的限制，系统将限制容器。下面是这个场景的示例，我认为op是询问超出限制的吊舱会发生什么，而不是计划。

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-test
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    resources:
      limits:
        cpu: "100"
      requests:
        cpu: "100"
    args:
    - -cpus
    - "2"