Feedback

Chat Icon

Cloud-Native Microservices With Kubernetes - 2nd Edition

A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in Kubernetes

Priority Mechanisms in Kubernetes: QoS and PriorityClass
44%

Quality of Service (QoS) Classes

By defining resource requests and limits for your containers, you are indirectly influencing the Quality of Service (QoS) class assigned to the Pod by Kubernetes. This is an important concept to understand, as it affects how Pods are treated under resource pressure on a node.

Kubernetes uses Quality of Service (QoS) classes to define the performance characteristics of a Pod. The class of a Pod is determined by the resource requests and limits of its containers.

These are the three QoS classes that Kubernetes supports:

  • Guaranteed
  • Burstable
  • BestEffort

We are going to explore these classes from the highest to the lowest priority. We are also going to use the Pod object for our examples instead of Deployments to keep code snippets shorter. Obviously, the same principles apply to Deployments as well.

Guaranteed: Strict Resource Guarantees

For a Pod to be considered Guaranteed, all of its containers must have the following characteristics:

  • A memory limit and a memory request are set.
  • The memory limit is equal to the memory request.
  • A CPU limit and a CPU request are set.
  • The CPU limit is equal to the CPU request.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: guaranteed-container
    image: 
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "64Mi"
        cpu: "250m"

Guaranteed is the strictest QoS class. When a Pod is set to Guaranteed, it means that the container runtime will guarantee that the Pod never exceeds its resource limits. If it does, the Pod will be killed.

Burstable: Flexible Resource Allocation

A Pod is called Burstable when it satisfies the following criteria:

  • The Pod is not Guaranteed. This means that the requests value differs from the limits value for CPU and memory in all containers.
  • At least one container has a memory or CPU request or limit.

Here is an example:

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: burstable-container
    image: 
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu

Cloud-Native Microservices With Kubernetes - 2nd Edition

A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in Kubernetes

Enroll now to unlock all content and receive all future updates for free.