ESO 0.16.2 is the one release that serves both v1beta1 and v1. 0.17
stops serving v1beta1, so manifests still on v1beta1 would fail to sync
from the next hop on. For these resources the schemas are name-identical
(conversion strategy None); only the apiVersion changes.
Needed from ESO 0.19, whose CRDs are too big for client-side apply. Turned on now, on 0.10.7, so Argo CD migrates the managed fields before the upgrade starts.
Dropping the anti-affinity wasn't enough: during the rollout the old ReplicaSet kept recreating its pod with the old anti-affinity, which still blocked the new one. Recreate stops the old pod first; nothing uses the injector, so the short gap doesn't matter.
The chart requires injector pods on different nodes. With one node and one replica the rolling update to vault-k8s 1.7.6 deadlocked: the new pod stayed Pending until the old one left, which waits for the new one. The server already sets affinity to "" for the same reason.
Chart 0.28.1 is only tested up to Kubernetes 1.30. 0.34.1 brings the
injector to vault-k8s 1.7.6. The server image is pinned to the running
1.17.2: the StatefulSet uses OnDelete, so nothing restarts now, but a
later pod restart would otherwise pull the chart's default and Shamir
unsealing needs the keys at hand for a Vault upgrade. Rendered with the
pin, the StatefulSet only changes in formatting and an extra check in the
config script that doesn't apply here.
Pin authentik-postgres to the image CNPG filled in at creation
(postgresql:17.4). Later operators default to PostgreSQL 18, and since
1.26 a higher major in the image triggers an offline in-place major
upgrade. immich-postgres already pins its pgvecto.rs image.
Turn on ENABLE_INSTANCE_MANAGER_INPLACE_UPDATES so the five operator hops
(1.25 -> 1.30, one minor at a time as the docs recommend) swap the
instance manager inside the running pods instead of restarting both
single-instance databases each time.
Velero 1.15 is only tested up to Kubernetes 1.31; 1.16 is tested on 1.33.
The AWS plugin moves along to v1.12.2. Argo CD applies the chart's crds/
directory itself, so the CRD schema update doesn't need the disabled
upgrade hook. No backup was running.
All certificates stayed Ready through the five hops, and a test Certificate for s2.rubenhensen.nl was issued by Let's Encrypt over HTTP-01. The 1.19 chart left a duplicate tokenrequest RoleBinding behind, removed by hand.
One minor at a time from v1.15.5 to v1.20.4 on the way to Kubernetes 1.33, see docs/upgrade-k8s-1.33.md. The chart renders the current values unchanged.
One minor at a time from v1.15.5 to v1.20.4 on the way to Kubernetes 1.33, see docs/upgrade-k8s-1.33.md. The chart renders the current values unchanged.
One minor at a time from v1.15.5 to v1.20.4 on the way to Kubernetes 1.33, see docs/upgrade-k8s-1.33.md. The chart renders the current values unchanged.
One minor at a time from v1.15.5 to v1.20.4 on the way to Kubernetes 1.33, see docs/upgrade-k8s-1.33.md. The chart renders the current values unchanged.
One minor at a time from v1.15.5 to v1.20.4 on the way to Kubernetes 1.33, see docs/upgrade-k8s-1.33.md. The chart renders the current values unchanged.
Last hop of the Longhorn upgrade for Kubernetes 1.33. Stays on 1.11.2:
1.11.3 ships csi-provisioner v6.3.0 and needs Kubernetes 1.34. The
1.11.2 chart still declares kubeVersion >=1.25 and ships csi-provisioner
v5.3.0, and renders our values unchanged.
Checked beforehand: 17 healthy volumes plus 2 detached, no backing
images, system backup pre-upgrade-v1-10-2-202610221449 is Ready. PV
nodeAffinity recorded to compare after the upgrade (1.11.0 had a
regression there, fixed in 1.11.2).
Third hop towards 1.11.2. 1.10 removes the longhorn.io/v1beta1 API, which
requires every Longhorn CRD to store only v1beta2; all 22 already do (the
check from the 1.10 important notes). Settings move to a per-data-engine
JSON format, but the chart renders our defaultSettings and
defaultBackupStore values unchanged.
Checked beforehand: 17 healthy volumes plus 2 detached, no backing
images, system backup pre-upgrade-v1-9-2-202610221421 is Ready.