Skip to content

Latest commit

 

History

History
41 lines (21 loc) · 2.51 KB

pod-disruption-budget-preflights.md

File metadata and controls

41 lines (21 loc) · 2.51 KB

PDB upgrade preflight validations for CLI

Introduction

Pod disruptions budgets (pdb) are a way to stop pods from getting disrupted while performing voluntary actions like draining nodes, etc. A pdb depends on how the application is designed and how much it can tolerate disruptions. A very strict pdb that doesn’t allow even a single node to drain is problematic and will not let operations like upgrade succeed. We want to provide the users with this information regarding pdbs set on target clusters so that we fail early on upgrades.

More here on PDBs https://kubernetes.io/docs/tasks/run-application/configure-pdb/

Proposed EKS-A changes

In upgrade pre-flights, we check if there is a pdb set on the target cluster. If any pdb is detected on the cluster, we throw an error and fail upgrade.

After failing upgrade if the customer still wants to proceed with upgrade, we will introduce a flag which ignores this warning and proceeds with the upgrade. This would indicate a conscious decision made by the user to bypass warnings.

Out of Scope

Validating PDBs where we check for type of upgrade requests coming through and accordingly error out. PDBs are an implementation that customers have configured for their applications and we won’t be further validating those on EKSA side.

Situations/Cases covered

  1. PDB detected on the cluster with associated pods
    • ERROR Upgrade command for cluster with PDB set for disruptions fails at the preflight check level where we give a user a remediation to use the --skip-validations flag along with --no-timeout flag. Without the --skip-validations flags used, we always have a hard failure for upgrades.
  2. --skip-validations podDisruption
    • If this flag is specified with the podDisruption as one of the args, we skip our validations for PDB and let the upgrade succeed.

Implementation

Implementation details would be addressed in a different one pager, however, we will discuss the addition of a new flag in this doc. We will be introducing a new flag for the upgrade command namely --skip-validations .

Usage: eksctl anywhere upgrade cluster -f cluster.yaml --skip-validations podDisruption

This flag would take in a list of comma separated strings. These names would need to be valid values for validations that EKSA will skip. Even though today we will have only one supported validation to skip, in the future the use can be extended to multiple validations ie

eksctl anywhere upgrade cluster -f cluster.yaml --skip-validations podDisruption,preflight