Home > Software design >  Guaranteed Application pods is in Pending state when dummy guaranteed pods are Running
Guaranteed Application pods is in Pending state when dummy guaranteed pods are Running

Time:02-24

In my project, need to test that Guaranteed Application pods should evict any dummy application pods which are running. How do I achieve this such that application pods are always highest priority.

CodePudding user response:

You can make use of kind: PriorityClass to give your application a higher priority then normal pods.

CodePudding user response:

The eviction is based on the priority of the Pod, QoS, and the actual usage of the Pod. If the Pod belongs to a higher priority pod, its creation will preempt the bestEffort, followed by burstable followed by guaranteed pods.

For example: In my cluster, I have the following priority classes:

kubectl get priorityclasses.scheduling.k8s.io 
NAME                      VALUE        GLOBAL-DEFAULT   AGE
k8s-cluster-critical      1000000000   false            11d
system-cluster-critical   2000000000   false            11d
system-node-critical      2000001000   false            11d

For the sake of example, I used the system-cluster-critical class. Do not do this, have your priority class. The following Pod would lead to the eviction of other pods.

---
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed
spec:
  nodeName: kube-worker-1
  priorityClassName: system-cluster-critical
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: 1000m
        memory: 300Mi
      limits:
        cpu: 1000m
        memory: 300Mi

In the description of the other pods, you would see the following:

Events:
  Type     Reason      Age    From     Message
  ----     ------      ----   ----     -------
  Normal   Pulling     3m19s  kubelet  Pulling image "nginx"
  Normal   Pulled      3m19s  kubelet  Successfully pulled image "nginx" in 495.693296ms
  Normal   Created     3m19s  kubelet  Created container app
  Normal   Started     3m19s  kubelet  Started container app
  Warning  Preempting  18s    kubelet  Preempted in order to admit critical Pod
  Normal   Killing     18s    kubelet  Stopping container app

CodePudding user response:

The answer provided by the P.... is very good and useful. By Pod Priority and Preemption you can achieve what you are up to.

However, apart from that, you can use dedicated solutions, for example in the clouds. Look at the Google cloud example:

Before priority and preemption, Kubernetes pods were scheduled purely on a first-come-first-served basis, and ran to completion (or forever, in the case of pods created by something like a Deployment or StatefulSet). This meant less important workloads could block more important, later-arriving, workloads from running—not the desired effect. Priority and preemption solves this problem.

Priority and preemption is valuable in a number of scenarios. For example, imagine you want to cap autoscaling to a maximum cluster size to control costs, or you have clusters that you can’t grow in real-time (e.g., because they are on-premises and you need to buy and install additional hardware). Or you have high-priority cloud workloads that need to scale up faster than the cluster autoscaler can add nodes. In short, priority and preemption lead to better resource utilization, lower costs and better service levels for critical applications.

Additional guides for other clouds:

See also this useful tutorial.

  • Related