From 47888f61c92281c8a73ebf39c80fdab4f1cc1167 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Filip=20K=C5=99epinsk=C3=BD?= Date: Thu, 8 Dec 2022 01:17:51 +0100 Subject: [PATCH] Add Eviction policy for unhealthy Pods guarded by PDBs blog post --- ...6-unhealthy-pod-eviction-policy-for-pdb.md | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 content/en/blog/_posts/2023-01-06-unhealthy-pod-eviction-policy-for-pdb.md diff --git a/content/en/blog/_posts/2023-01-06-unhealthy-pod-eviction-policy-for-pdb.md b/content/en/blog/_posts/2023-01-06-unhealthy-pod-eviction-policy-for-pdb.md new file mode 100644 index 0000000000000..bf40a015621c7 --- /dev/null +++ b/content/en/blog/_posts/2023-01-06-unhealthy-pod-eviction-policy-for-pdb.md @@ -0,0 +1,76 @@ +--- +layout: blog +title: "Eviction policy for unhealthy pods guarded by PodDisruptionBudgets" +date: 2023-01-06 +slug: "unhealthy-pod-eviction-policy-for-pdbs" +--- + +**Authors:** Filip Křepinský (Red Hat), Morten Torkildsen (Google), Ravi Gudimetla (Apple) + +## What problems does this solve? + +Eviction of pods respects Pod Disruption Budgets (PDBs). This means that the eviction of a pod +should not disrupt a guarded application and `.status.currentHealthy` of a PDB should not fall +bellow `.status.desiredHealthy`. Running pods that are [Unhealthy](/docs/tasks/run-application/configure-pdb/#healthiness-of-a-pod) +do not count towards the PDB status, but eviction of these is only possible in case the application +is not disrupted. This helps disrupted or not yet started application to achieve availability +as soon as possible without additional downtime that would be caused by evictions. + +Unfortunately, this poses a problem for cluster administrators that would like to drain nodes +without any manual interventions. Misbehaving applications with pods in `CrashLoopBackOff` +state (due to a bug or misconfiguration) or pods that are simply failing to become ready +make this task much harder. + +On the other hand there are users that depend on the current behavior to: +- prevent data-loss that would be caused by deleting pods that are guarding an underlying resource or storage +- achieve the best availability possible for their application + +We are introducing a new field `spec.unhealthyPodEvictionPolicy` for PDBs to support both of these requirements. + +## How does it work? + +There are two policies `IfHealthyBudget` and `AlwaysAllow` to choose from. +The former conforms to the original behavior to achieve the best availability. +This will be also used when no policy is specified. + +By setting `AlwaysAllow` policy to the `spec.unhealthyPodEvictionPolicy` field of your PDB, +you are choosing the best effort availability for your application. +This will make it easier to maintain and upgrade your clusters. + +Eviction API will consider these policies when eviction of a pod that is guarded by a PDB is requested. + + +## How do I use it? + +This is an alpha feature, and you have to switch on the feature gate to enable it with the command line flag `--feature-gates=PDBUnhealthyPodEvictionPolicy=true` on `kube-apiserver`. + +Deploy an nginx application with `app: nginx` label. + +Create a PDB with `AlwaysAllow` policy to guard this application. + +```yaml +apiVersion: policy/v1 +kind: PodDisruptionBudget +metadata: + name: nginx-pdb +spec: + selector: + matchLabels: + app: nginx + maxUnavailable: 1 + unhealthyPodEvictionPolicy: AlwaysAllow +``` + + +## How can I learn more? + + +- Read the KEP: [Unhealthy Pod Eviction Policy for PDBs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/3017-pod-healthy-policy-for-pdb) +- Read the documentation: [Unhealthy Pod Eviction Policy](/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy) for Pod Disruption Budgets +- Review [Pod Disruption Budgets](docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets), [Draining of Nodes](docs/tasks/administer-cluster/safely-drain-node/) and [Eviction](docs/concepts/scheduling-eviction/api-eviction/) + + +## How do I get involved? + +If you have any feedback, please reach out to us in the [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on Slack (visit https://slack.k8s.io/ for an invitation if you need one), or on the SIG Apps mailing list: kubernetes-sig-apps@googlegroups.com +