为什么具有相同请求和限制的一个容器的 pod 被归类为 Burstable pod？

Question

在此处的kubernetes 文档中Burstable，根据资源 QOS分类的 pod 的条件定义为

如果为一个或多个容器中的一个或多个资源设置了请求和可选限制（不等于 0），并且它们不相等，则该 Pod 被归类为 Burstable。当未指定限制时，它们默认为节点容量。

所以基本上不同地说：

1. requests为pod 中的一个或多个容器中的一个或多个资源（cpu/内存）设置。
2. limits可选：如果设置，就应该不等于对requests同一资源。

但是后来在文档中给出了以下作为Burstablepod的示例：

containers:
  name: foo
    resources:
      limits:
        cpu: 10m
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 1Gi

  name: bar

注意： Containerbar没有指定资源。

此示例满足条件 1。但是，它不满足条件 2，因为为一个容器设置了限制和请求，但它们是相等的。

那么为什么这个吊舱被归类为Burstable吊舱呢？

包含 QOS 解释和示例的 K8s 文档：https : //github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md#qos-classes

Answer 1

服务质量（QoS）的评估是由调度程序在整个pod上完成的，即一个容器一个容器，然后取最低的评估。

看看这个例子：

apiVersion: v1
kind: Pod
metadata:
  name: class
spec:
  containers:
  - name: container1
    image: busybox
    command: ["sh"]
    args: ["-c","sleep 3600"]
    resources:
      requests:
        memory: 100Mi
        cpu: 200m
      limits:
        memory: 100Mi
        cpu: 200m
  - name: container2
    image: busybox
    command: ["sh"]
    args: ["-c","sleep 3600"]
    resources:
      requests:
        memory: 100Mi
        cpu: 200m

container1 具有保证的 QoS，因为它同时定义了请求和限制，并且它们是相等的。

container2 具有 Burstable QoS，因为它没有定义限制，而只有请求。

类 pod 被评估，基于两个容器并取最低评估：

min(Guaranteed, Burstable) = Burstable

参考：https : //kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/