Envoy runs as a DaemonSet on host ports 10080 and 10443 for now, so it can be tested next to ingress-nginx, which keeps 80 and 443. The Gateway has a plain HTTP listener and no routes yet.
First step of the move from the retired ingress-nginx to the Gateway API. This installs the controller with the Gateway API and Envoy Gateway CRDs. No Gateway exists yet, so no traffic changes.
1.21 supports Kubernetes 1.33 to 1.36. The chart no longer creates the tokenrequest Role and RoleBinding; nothing uses them, as the only issuer is ACME with HTTP-01 and no serviceAccountRef.
Argo CD 3.x adds pre-delete-finalizer.argocd.argoproj.io and its /cleanup variant to Applications with PreDelete hooks, which the Longhorn chart has. With only resources-finalizer in git, the apps app-of-apps stayed OutOfSync on helm-longhorn.
Required from 3.3, whose ApplicationSet CRD no longer fits the last-applied annotation of client-side apply. Turned on while still on 3.2 so the managed-field migration happens before the CRD grows.
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.
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.
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.
Second hop towards 1.11.2. 1.9 stops serving longhorn.io/v1beta1 (nothing
in this repo uses it) and renames orphan-auto-deletion (false here) to
orphan-resource-auto-deletion during the upgrade. Chart values are
unchanged from 1.8.2.
Checked beforehand: 17 healthy volumes plus 2 detached, no backing
images, every Longhorn CRD already stores only v1beta2, and system backup
pre-upgrade-v1-8-2-202610221408 is Ready.
First hop from 1.7.3 to 1.11.2 (docs/upgrade-k8s-1.33.md). 1.8 drops the
backup-target settings in favour of a "default" BackupTarget resource, so
the NFS target and poll interval move into defaultBackupStore. Until now
they only lived in the cluster.
Checked beforehand: no Faulted volumes, no backing images, all volumes on
engine v1.7.3, system backup pre-upgrade-v1-7-3-20261022 and Velero
backup pre-longhorn-1-8-202610221326 both complete.
concurrentAutomaticEngineUpgradePerNodeLimit was 0, so volumes stayed on
the engine image of whatever Longhorn version created them: three on
1.7.1, nine on 1.7.2, seven on 1.7.3. Every hop of the upgrade to 1.11.2
needs all volumes on the current engine first.