abhioncbr

---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-preempting
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "This priority class will cause other lower priority pods to be preempted."
---

abhioncbr

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

abhioncbr

Again, like last time, I am starting this post by acknowledging & thanking the appreciation for my previous posts on pod-eviction. This post is the third one on pod eviction.

• Please don’t evict my pod; QoS class.
• Please don’t evict my pod; eviction policy.
• The current one, Please don’t evict my pod; priority & disruption budget.

In this post, we are going to cover the pod priority class, pod disruption budget, DaemonSet and the relationship of these constructs with pod eviction. Okay, enough of talking, let’s start with pod priority class.

PriorityClass and Preemption

PriorityClass is a stable Kubernetes object from version 1.14, and it is a part of the scheduling group used for defining a mapping between priority class name, and the integer value of the

abhioncbr

I will start this post by acknowledging the appreciation for my last post; This post is in continuation to my previous post, here is the list of post.

• Please don't evict my pod; QoS class.
• The current one, Please don't evict my pod; eviction policy

Let's first quickly revisit the understanding from the last post; pod QoS class determines which pod will remove first from a node in-case of eviction by Kubelet. There are three types of QoS classes, i.e. Best Effort, Burstable & Guaranteed and among them Best Effort pods will evict first, following Burstable pods second and at last the Guaranteed one.

In this post, we are going to cover node resources, what causes eviction, what are soft and hard threshold signals. Let's start with node resources.

Node resources

abhioncbr

import time

some_str = ''
while True:
 some_str = some_str + ' * hello * ' * 1024000
 print(some_str)

 # sleep for sometime
 print('Before: %s' % time.ctime())
 time.sleep(20)

abhioncbr

---
apiVersion: v1
kind: Namespace
metadata:
  name: evict-example
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority

abhioncbr

It was the second day of the long weekend; I was watching Money Heist on Netflix (a good one to watch, free recommendation by a human), and in-between, I got the slack notification on one channel, "Is something wrong with our application?" By the time I will start my MacBook to check, another slack message "application is not running, pod status says Evicted." Luckily, the application was in a pre-prod environment, but we want pod up & running. It looks like an effortless task; restart the pod, right? We did, pod evicted again in some time. The application code was simple and shouldn't be consuming many resources of the K8s cluster. Frankly, before this, we haven't encountered such an issue, and we weren't sure about the solution, and there start a saga of pod eviction resolution. Eviction is a complex topic, many factors, objects and policies involved; Let's get started with basics and slowly building the related corresponding concepts. In this first post, I am targeting to cover the pod phase, status,

abhioncbr

---
apiVersion: batch/v1
kind: Job
metadata:
  name: descheduler-job
  namespace: kube-system
spec:
  parallelism: 1
  completions: 1
  template:

abhioncbr

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler-policy-configmap
  namespace: kube-system
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"

abhioncbr

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: descheduler-cluster-role
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update"]