Bahriya Kubernetes Engine 2.4.0 is released. It is a minor release: it changes the kubelet’s configuration and adds a daily backup job for Longhorn. No Kubernetes, containerd, Calico or component version moves. Exact versions are in the release notes in the Mamluk Console.
Each node is upgraded in turn and drained first, and its kubelet restarts. Plan it as a maintenance window.
The kubelet removes unused images sooner
On a cluster with no image garbage collection setting of its own, the kubelet now removes images no container uses once their disk is 70% used, down to 60%, instead of the kubelet’s defaults of 85% and 80%.
Where Longhorn’s disk is the node’s own filesystem, the earlier thresholds let the disk fill past the point at which Longhorn stops placing replicas, so a replica lost in a drain was not rebuilt on that node. At 70% the kubelet acts first. A threshold your cluster already sets is kept, and kubelet.imageGC in config.yaml sets others.
Images are removed sooner, so a node pulls more images again after a drain. Confirm that every node can reach the registry before the window.
check.sh and Longhorn’s disks
check.sh compares each Longhorn disk with Longhorn’s free-space floor and with the kubelet’s image threshold. A disk below the floor is a failure for 2.4.0, because Longhorn places no new replica on it, and the report says how to free space.
A daily backup of every volume
A Longhorn backup target says where backups go; it schedules none. BKE 2.4.0 can create a daily backup job for every volume that has no recurring job of its own. It is off unless config.yaml turns it on, keeps the newest seven backups of each volume unless told otherwise, and never touches a job you created. Where the job exists, check.sh fails a volume whose newest backup is older than a limit you can set.
Upgrading
Clusters upgrade from 2.3.x. A minor release cannot be skipped, and check.sh refuses an attempt to skip one; run it on a control-plane node days before the window, and free space on any Longhorn disk it reports below the floor.
The order is the usual one: upgrade.sh on the first control-plane node, then on each other node in turn, draining it first and uncordoning it afterwards, then apply.sh for the components. As with every BKE upgrade, apply.sh first reports each change against your own values files and changes nothing until you run it with --commit. Turn on daily backups in config.yaml before the apply.sh run if you want them. The full sequence is in the documentation.