More Info:
Advisory: define a PodDisruptionBudget for each multi-replica Deployment so node drains and rollouts keep a minimum number of pods available.Risk Level
InformationalAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
On any machine with kubectl access, list non-compliant multi‑replica Deployments so you know what needs a PodDisruptionBudget:
-
For one non‑compliant Deployment, capture its pod template labels and replica count (needed for the PDB selector and minAvailable / maxUnavailable):
-
On any machine with kubectl access, create a PodDisruptionBudget manifest file for that Deployment, using the pod template labels in
spec.selector.matchLabels. For example, save aspdb-<deployment-name>.yaml:AdjustminAvailable(or alternatively usemaxUnavailable) according to how many replicas must remain available during disruptions. -
Apply the PodDisruptionBudget:
-
Repeat steps 2–4 for each remaining non‑compliant multi‑replica Deployment identified in step 1, ensuring each PDB’s
spec.selector.matchLabelsexactly matches the Deployment’s pod template labels you want protected. -
Verify all multi‑replica Deployments now have at least one matching PodDisruptionBudget by rerunning the audit command on any machine with kubectl access:
Confirm that every listed multi‑replica Deployment now shows
is_compliant=trueandpodDisruptionBudgetsgreater than 0.
Using kubectl
Using kubectl
metadata.namespacematches the Deployment’s namespace.spec.selector.matchLabelsexactly matches the labels on.spec.template.metadata.labelsof the Deployment’s pods (at least one stable, unique label such asapp: <name>).
Automation
Automation

