Kubernetes Pod QoS

March 14, 2021

关于QoS的基本概念和使用，这里就不在赘述了

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

这里主要是为了解释一个问题

QoS 是作用在 Pod 上的，但是决定 QoS 的 resources 却是作用于 container 上的，那么，在一个Pod上只有一个 container 的情况下，这个问题就变得非常简单

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: lizhe
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

当两个 container 使用的 request 都一致时

container1

requests 200,700 limits 200,700

container2

requests 300,800 limits 300,800

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: lizhe
spec:
  containers:
  - name: qos-demo-ctr1
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"
  - name: qos-demo-ctr2
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "300Mi"
        cpu: "800m"
      requests:
        memory: "300Mi"
        cpu: "800m"

如果container2 的 requests 和 limits 不一致，那对于 container2 而言，qos 应该是burstable，而 container1 由于是一致的，则应该是 Guaranteed

container1

requests 200,700 limits 200,700

container2

requests 200,700 limits 300,800

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: lizhe
spec:
  containers:
  - name: qos-demo-ctr1
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"
  - name: qos-demo-ctr2
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "300Mi"
        cpu: "800m"
      requests:
        memory: "200Mi"
        cpu: "700m"

结果是，不可以这样

Burstable

结论

QoS 确实是作用于 Pod

决定QoS的是container容器的 resources