Pod Priority and Preemption in Kubernetes

Pod Priority and Preemption in Kubernetes

  • May 4, 2019
Table of Contents

Pod Priority and Preemption in Kubernetes

Kubernetes is well-known for running scalable workloads. It scales your workloads based on their resource usage. When a workload is scaled up, more instances of the application get created.

When the application is critical for your product, you want to make sure that these new instances are scheduled even when your cluster is under resource pressure. One obvious solution to this problem is to over-provision your cluster resources to have some amount of slack resources available for scale-up situations. This approach often works, but costs more as you would have to pay for the resources that are idle most of the time.

Pod priority and preemption is a scheduler feature made generally available in Kubernetes 1.14 that allows you to achieve high levels of scheduling confidence for your critical workloads without overprovisioning your clusters. It also provides a way to improve resource utilization in your clusters without sacrificing the reliability of your essential workloads. Kubernetes Cluster Autoscaler is an excellent tool in the ecosystem which adds more nodes to your cluster when your applications need them.

However, cluster autoscaler has some limitations and may not work for all users:

Source: kubernetes.io

Share :
comments powered by Disqus

Related Posts

Detecting the Kubernetes API server DoS vulnerability (CVE-2019-1002100).

Detecting the Kubernetes API server DoS vulnerability (CVE-2019-1002100).

Recently, a new Kubernetes related vulnerability was announced that affected the kube-apiserver. This was a denial of service vulnerability where authorized users with write permissions could overload the API server as it is handling requests. The issue is categorized as a medium severity (CVSS score of 6.5) and can be resolved by upgrading the kube-apiserver to v1.11.8, v1.12.6, or v1.13.4.

Read More
Tinder’s move to Kubernetes

Tinder’s move to Kubernetes

Almost two years ago, Tinder decided to move its platform to Kubernetes. Kubernetes afforded us an opportunity to drive Tinder Engineering toward containerization and low-touch operation through immutable deployment. Application build, deployment, and infrastructure would be defined as code.

Read More