QoS class of Guaranteed: every container in a pod has same settings for limits and requests on CPU/RAM.
QoS class of Burstable: At least one Container in the Pod has a memory or cpu request.
QoS class of BestEffort: the Containers in the Pod must not have any memory or cpu limits or requests.
If you don’t specify a CPU/RAM limit for a Container, then one of these situations applies:
- The Container has no upper bound on the CPU/RAM resources it can use. The Container could use all of the CPU/RAM resources available on the Node where it is running.
- The Container is running in a namespace that has a default CPU/RAM limit, and the Container is automatically assigned the default limit. Cluster administrators can use a LimitRange to specify a default value for the CPU/RAM limit.
In the configuration file, the args section provides arguments for the Container when it starts. The Container will attempt to allocate 2 CPUs at startup, which is well below the requested and limited 100 CPUs, but because the Node itself only has 4 CPUs, this will result in
Insufficient cpu failure.
apiVersion: v1 kind: Pod metadata: name: cpu-demo-2 namespace: cpu-example spec: containers: - name: cpu-demo-ctr-2 image: vish/stress resources: limits: cpu: "100" requests: cpu: "100" args: - -cpus - "2"
In the configuration file, the args section provides arguments for the Container when it starts. The Container will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limit. This will result in OOMkill failure as it’s out of memory.
apiVersion: v1 kind: Pod metadata: name: memory-demo-2 namespace: mem-example spec: containers: - name: memory-demo-2-ctr image: polinux/stress resources: requests: memory: "50Mi" limits: memory: "100Mi" command: ["stress"] args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]