By nature, pods in Kubernetes clusters are ephemeral. They can be created, killed, and moved around by the scheduler. This may occasionally cause disruption in the microservices if pods are not configured properly.

In this article, we will look at two scenarios which will impact the stability of pod because of pod eviction:

• Pod preemption
• Out of resource eviction

And how we can secure our pods by ensuring:

• Quality of Service
• Pod Priority

Quality of Service

There is no direct method to specify Quality of Service (QoS) of pods. Kubernetes determines quality of service based on the resource request and limit of the pods.

Each container specifies a request for resource, which is the amount of resource that is guaranteed by the Kubernetes, and a limit for resource which is the maximum amount of resource Kubernetes will allow the container to use.

Pod level request and limit are computed by adding per-resource level requests and limits across all containers of the pod. Kubernetes currently provides three QoS based on pod level request and limit

Guaranteed

• Every container in pod has CPU request and limit with request == limit
• Every container in pod has memory request and limit with request == limit

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-nginx
  namespace: demo
spec:
  containers:
  - name: guaranteed-nginx
    image: nginx
    resources:
      limits:
        memory: "512Mi"
        cpu: "1024m"
      requests:
        memory: "512Mi"
        cpu: "1024m"

• 

Burstable

• At least one container has memory and CPU request
• Pod should not meet the criteria of Guaranteed as mentioned above

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-nginx
  namespace: demo
spec:
  containers:
  - name: guaranteed-nginx
    image: nginx
    resources:
      limits:
        memory: "1024Mi"
      requests:
        memory: "512Mi"

#kubernetes #containers #technology #k8s #devops #docker #microservices #kubernetes-cluster