Kubernetes Pod QoS
关于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
- 所有容器 requests 和 limits 都一致,Guaranteed
- 有不一致的,Burstable
- 都没有配置,Best-Effort