Files
Andrey Kolkov 33fa5e51b0 fix(etcd): fix etcd-operator 1.5->1.6 upgrade (immutable selector + OOM floor)
Two defects that break the etcd-operator on an in-cluster 1.5 -> 1.6 upgrade
(#2859 swapped the upstream chart for the cozystack-authored one):

- #3242: the controller Deployment's spec.selector.matchLabels changed
  ({instance,name} -> {name,control-plane}). spec.selector is immutable, so
  `helm upgrade` cannot patch the existing Deployment and the whole HelmRelease
  upgrade fails ("field is immutable") -- the operator and the v1alpha2 CRDs it
  serves never come up, which blocks the etcd v1alpha2 adoption. Fresh installs
  use the new selector directly, so fresh-install CI does not catch it. Add a
  pre-upgrade hook that deletes the Deployment ONLY when its live selector is
  the pre-1.6 one (lacks control-plane=controller-manager), so Helm recreates it
  cleanly. No-op when the selector already matches (rc.1 -> later) and never
  runs on a fresh install (pre-upgrade only). Keeping the selector stable in the
  chart is not an option: rc.1 already shipped the new selector, so aligning it
  back would merely move the immutable break to rc.1 -> next.

- Raise the manager's cold-start memory limit floor 128Mi -> 256Mi (and the VPA
  minAllowed to match). The steady-state working set is ~250Mi (the VPA's own
  recommendation); at 128Mi a Pod that starts before the VPA admission webhook
  rewrites it (e.g. a Deployment recreated out of band, or the webhook briefly
  unavailable during upgrade) OOMKills into a crash loop. Defense in depth so
  the operator never depends on VPA timing merely to avoid crashing; the VPA
  still scales it further under load up to maxAllowed.

Verified live on a 1.5 -> 1.6 adoption: the delete-Deployment step plus the VPA
re-applying 256Mi+ let the operator come up and the adoption complete.

Refs: #3242, #3243

Signed-off-by: Andrey Kolkov <androndo@gmail.com>
2026-07-09 18:23:59 +04:00
..