reconsider the benefit of pdb-minavailable-check Kyverno policy

The pdb-minavailable-check policy today is acting as an admission webhook preventing non-conforming Deployment and StatefulSet from being setup.

This is not great because it makes all create/update operations on all Deployment and StatefulSet go through Kyverno webhook (with an exception for some namespaces), which is introduces a fragility point because of scenarios where Kyverno webhook would not be available.

We have another policy, pdb-minavailable-audit which does the same check, but as a background/audit policy. We could possibly consider keeping only that one.

Option 1: keep both policies

Pros:

  • with !3352, we would fully block the possiblity of problematic PDBs in workload clusters

Cons:

  • drawbacks mentioned in the intro

Option 2: keep only the background/audit policy (``pdb-minavailable-audit`)

Pros:

  • addresses the drawbacks mentioned in the intro

Cons:

  • problematic PDBs in workload clusters would only result in Kyverno Policy reports: would ops see them ?
    • on the other hand...
      • we've lived without any of these policies for workload clusters, and this hasn't caused problems, to my knowledge, so broken PDBs must not be that frequent ?
      • the introduction of a background/audit policy would still be an improvement
      • would we really want to block CNF/apps deployments if they have a broken PDB ?

🎯 Work progressed in !7046 (merged) to implement Option 2

Edited by Thomas Morin