Question

在kubernetes documentation here中，关于资源QOS的分类为Burstable的Pod的条件定义为

如果为以下一项或多项设置了请求和可选的限制（不等于0）跨越一个或多个容器的更多资源，它们是不相等的，然后将该广告连播分类为“突发”。当没有限制时指定，它们默认为节点容量。

所以基本上有不同的说法：

requests为Pod中的一个或多个容器中的一个或多个资源（CPU /内存）设置。
limits是可选的：如果设置，则它们应不等于 资源。

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

Burstable

注意：容器containers: name: foo resources: limits: cpu: 10m memory: 1Gi requests: cpu: 10m memory: 1Gi name: bar未指定资源。

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

那为什么将此吊舱归类为bar吊舱？

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

Answer 1

The evaluation of the Quality of Service (QoS) is done by scheduler on the whole pod, i.e. container by container and then taking the lowest evaluation.

Take a look at this example:

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 has Guaranteed QoS, because it has both requests and limits defined, and they are equals.

container2 has Burstable QoS, because it hasn't limits defined, but only requests.

class pod is evaluated, based on both containers and taking the lowest evaluation:

min(Guaranteed, Burstable) = Burstable

Reference: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

为什么将具有相同请求和限制的容器的容器分类为可爆裂的容器？

1 个答案: