First step from 1.11.2 to 1.13 now that the cluster runs Kubernetes 1.35. The internal NetworkPolicies that 1.12 enables by default stay off: Calico would enforce them, and the instance-manager policy only admits Longhorn pods while the iSCSI initiator connects from the host.
Also lifts the Renovate hold below 1.11.3, which only existed for Kubernetes 1.33.
No breaking changes for this setup: the chart renders the same resources and server flags, and chart 12 only dropped the Bitnami kubectl image from the CRD hook, which stays off because Argo CD applies the CRDs. The AWS plugin goes to v1.14.4, the line for Velero 1.18.
1.17 drops restic, which nothing here uses (all 411 pod volume backups and 20 repositories are kopia), and moves the maintenance job settings from server flags into the velero-repo-maintenance ConfigMap, which the chart now renders with keepLatestMaintenanceJobs: 3. The AWS plugin goes to v1.13.2, the line for Velero 1.17.
3.5 is tested on Kubernetes 1.32 to 1.36; 3.4 stops at 1.35. It renders Helm charts with Helm 4.2.1 instead of 3.19; rendering all thirteen Helm apps with both gave the same manifests apart from whitespace, comments and document order.
dqlite supports VACUUM from v1.18.2, which microk8s 1.34 ships, but the dqlite shell wraps every statement in a transaction and SQLite refuses to VACUUM inside one. dqlite-vacuum sends it through the go-dqlite driver instead and otherwise just prints page statistics. dqlite-vacuum.sh makes the backups first.
Rehearsed on opti1 on a throwaway node in /dev/shm: 657 MB to 41 MB in 0.6s, with concurrent writes unaffected and the data intact after restarts.
v1.34.9 runs with the dqlite snapshot tuning intact. LIST latency is unchanged from 1.33, so the ConsistentListFromCache stalls of canonical/microk8s#5568 don't show here.
k8s-dqlite v1.8.1 in microk8s 1.34 already bundles dqlite 1.18.2, so the database can be vacuumed from 1.34 on. Also notes the containerd 2 jump at 1.35, the feature gates the 1.34 hook adds for kine, and the front-proxy certificate that expired in 2025.
Longhorn now sits behind an authentik login on the Gateway instead of nginx basic auth, so the check expects a 302 without following it. Same change for s1 on node001.
ingress-nginx is gone and every app is served by the Envoy Gateway. The certificates were created by cert-manager's ingress-shim and are owned by the Ingresses, so each app now declares its Certificate itself, with the same name, secret and usages, so nothing gets reissued. gateway-shim can't take over because the certificates live in the app namespaces.
immich drops mbg.hensen.io, which has no route, so that one certificate is reissued through the Gateway's HTTP-01 solver.
Also removes the Longhorn test-port redirect URI and updates comments that still described nginx.
Longhorn has no users of its own; nginx guarded it with basic auth using apr1 hashes, which Envoy Gateway does not support. An Envoy Gateway SecurityPolicy now sends visitors through an authentik OIDC application that only admins may use. The client secret lives in Vault at kv/longhorn-oidc and reaches both authentik and Envoy through External Secrets.
Envoy moves from the test ports to 80 and 443, and Let's Encrypt HTTP-01 challenges go through an HTTPRoute on the Gateway. Push only after sudo microk8s disable ingress, since both want the same host ports.
With server.insecure, TLS ends at nginx or Envoy and argocd-server serves plain HTTP, which is how Argo CD documents the Gateway API setup. The nginx Ingress now talks HTTP to the http port; the ssl-passthrough annotation did nothing without the controller flag. argocd-folder diffs server-side for the new HTTPRoute.
Each app gets an HTTPS listener on the Gateway with its existing certificate, an HTTPRoute, and a ReferenceGrant for that certificate. The routes drop Envoy's 15s request timeout, as nginx has no overall limit either. Argo CD and Longhorn follow separately; the Ingresses stay until the switch-over.
The API server fills in Gateway API defaults such as the parentRef group and kind and a PathPrefix / match, so Argo CD's client-side diff kept gateway-folder OutOfSync.
First app on the Gateway API: an HTTPS listener for s2.rubenhensen.nl using the existing certificate in the gatus namespace, an HTTPRoute, and a ReferenceGrant for the certificate. Plain HTTP on the Gateway now redirects to HTTPS. The Ingress stays until the switch-over.
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.
The nightly backup of 2026-10-23 ended PartiallyFailed because a repository maintenance job pod finished while Velero was reading its emptyDir volumes. emptyDir holds nothing worth restoring, so a volume policy now skips it for both schedules.
The node runs v1.33.13 (snap revision 9067). kubelite logs the #5057 message but has not panicked or restarted, and the dqlite snapshot tuning carried over.
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.
Over the first 40 minutes after the restart: snapshots 24.7 minutes apart instead of ~3, none of 9,445 lease updates took over 4s, and neither the CNPG operator nor the snapshot-controller restarted.
1.34 brings the reworked k8s-dqlite write path, 1.36 a dqlite that can VACUUM the mostly empty datastore. Lists the per-hop checks, the one-way schema migration at 1.34, the components that still need to move for 1.35/1.36, and the staged dqlite tuning script on opti1.
The dqlite SQLite file is ~709 MB with 95% free pages, so every 1,024 commits dqlite writes a ~150 MB snapshot that stalls commits for seconds and makes controllers lose leader election. Plan: larger snapshot threshold in tuning.yaml now, microk8s 1.34+ for the real fix.
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.
Argo CD 3.0 switches the default to annotation tracking. Per the 2.14->3.0
upgrade notes, a resource whose first sync after the switch is a deletion
gets orphaned instead of pruned. Pinning label tracking (the 2.14 default,
so no change today) keeps the upgrade to 3.x free of that; moving to
annotations can follow once everything runs 3.4.
Ruben Hensen