Repository navigation
Move the platform's auto-vpa to the shared GeneratingPolicy form #5130
Description
🤖 Generated by the Agentic Engineer
Evidence
Prod runs Kyverno 1.19.1 and still sizes workloads through the classic auto-vpa ClusterPolicy. Kyverno plans to remove classic generate rules in 1.20. The shared catalog registers the GeneratingPolicy replacement (devantler-tech/kyverno-policies#1, item 3). The two prerequisites are merged: the guards admit the catalog's shape (#5105) with a system-namespace exclusion (#5127), and the VPA updater runs with --min-replicas=1 (#5086).
Read-only readback, 2026-10-20 ~16:15Z: 88 VPAs are labelled generate.kyverno.io/policy-name=auto-vpa (107 VPAs in total). Many running pods carry VPA-raised memory limits well above their authored ones. Examples: flux-operator 4.4Gi live against 1Gi authored, crossplane 1.5Gi against 512Mi, keda-operator 1.4Gi against 1000Mi.
Audience and problem
Platform operator: the platform has to move off the classic form before the Kyverno upgrade that removes it. The catalog's rollout moves a cluster in two separately reconciled steps, and the platform's classic VPAs are named <name>, not <name>-<kind>. So running both forms at once would put two VPAs on every workload.
Plan
- Unregister the classic policy and let it reconcile. Confirm that no
policy-name=auto-vpaVPA remains. - Register the catalog's three
GeneratingPolicyobjects, excludingkube-system,kube-public,kube-node-leaseandkyverno, where prod ships static VPAs. Confirm that every matching workload has exactly one VPA, and that a deleted workload's VPA is removed (the catalog relies onsynchronize, not owner references).
Keep the gap between the two steps short: a pod that restarts with no VPA comes back at its authored limits.
Acceptance criteria
- Step 1 deployed; 0 VPAs labelled
generate.kyverno.io/policy-name=auto-vpa. - Step 2 deployed; every Deployment, StatefulSet and DaemonSet outside the four system namespaces has exactly one generated VPA, and none of those namespaces gets one.
- The coroot alert autosuppressor's auto-vpa write-conflict exemption is updated or retired for the new policy names.
- Rollback is documented: the classic file stays registered-off until the move is verified.
Success signal
Both steps verified live with no duplicate or missing VPAs and no OOM restarts attributable to the gap.
Activity
devantler commentedon Oct 20, 2026
Step 1 deployed and verified (17:16Z). #5132 merged through the queue. Read-only readback after the deploy:
ClusterPolicy/auto-vpa: NotFound.generate.kyverno.io/policy-name=auto-vpa: 0, down from 88.Step 2 (#5134) is merged up to current
main, re-validated, and its CI was green before the update. Codex's three P2 findings are refuted with live evidence: the updater already runs--min-replicas=1, the longest workload name is 48 characters, and the owner-reference difference stays on this issue's delete check. Step 2 waits only on a green review at the new head.devantler commentedon Oct 20, 2026
Step 2 deployed and verified (#5134 merged 18:36Z). Read-only readback after the deploy:
GeneratingPolicyauto-vpa-deployment / -statefulset / -daemonsetkube-system/kube-public/kube-node-lease/kyvernoTwo items stay open on this issue:
ClusterPolicy/auto-vpaevents, which can no longer occur. I will check whether the new policies produce a write-conflict event shape before retiring or retargeting it.chore: agent-claim #5130 nonce=1937febe83c8ef78ce2c03b6b00bb907
devantler commentedon Oct 20, 2026
Orphan watch, 19:2xZ (~45 min after Step 2): read-only check of every VPA in the cluster against its target. 107 VPAs in total (88 generated + 19 static); 0 orphans — each
targetRefresolves to an existing Deployment, StatefulSet or DaemonSet. The remaining open item on this issue is the autosuppressor exemption, which platform#5137 retires.