The basic concept and use of QoS will not be repeated here
https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
This is mainly to explain a problem
QoS acts on the pod, but the resources that determine QoS act on the container. Then, when there is only one container on a pod, this problem becomes very simple
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"
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"
If the requests and limits of container2 are inconsistent, the QoS should be burstable for container2 and guaranteed for container1
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"
conclusion
QoS really works on pod
The QoS is determined by the resources of the container
All container requests and limits are consistent == guaranteed
There are inconsistencies == burstable
No configuration == best effort