Nothing changes in microk8s between 1.35 and 1.36 for this setup. The stable channels lag upstream patches, including the CVE-2026-2270 fix, so the snap gets held and patch updates become a deliberate step.
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.
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.
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.
Ruben Hensen