Bahriya Kubernetes Engine 2.2.0 is released. It is a minor release: it moves the container runtime and its configuration, Calico and Longhorn, and brings cert-manager, Netdata and Kong’s ingress controller to their latest patch releases. The Kubernetes version does not move. Exact versions, every one pinned to a patch, are in the release notes in the Mamluk Console.
The container runtime and Calico each restart something on every node, so this release drains nodes. Plan it as a maintenance window.
A new container runtime, and a place for your own settings
The container runtime moves one minor, and BKE 2.2.0 brings a new configuration file with it. The file states only the settings in which BKE differs from the runtime’s own defaults, written in the format the new version reads natively.
The upgrade replaces each node’s configuration file with BKE’s and keeps the previous file beside it, in the same step as the runtime upgrade, so the runtime restarts once on each node. Running containers keep running while it restarts.
Settings of your own now have a place of their own. BKE’s file reads every file in a separate directory after its own settings, and no BKE upgrade touches that directory. A change made to the main file before 2.2.0 is not carried over, so move it into that directory before you upgrade. The release notes give the paths and the format.
Longhorn’s own network policies are turned on
The previous release of Longhorn introduced network policies for its internal components, and BKE 2.1.0 turned them off until they had been tested on clusters built by BKE. They have been, and BKE 2.2.0 turns them on. Traffic into Longhorn’s pods is now allowed only from the Longhorn components that need it.
This changes network behaviour on upgrade. A pod outside Longhorn’s namespace can no longer reach Longhorn’s manager, and that includes a metrics scraper of your own. The Storage page of the documentation describes how to allow a scraper through, and how to turn the policies off if you need to.
Longhorn moves one minor. Volumes must be on the engine of the Longhorn release they run before the upgrade, and the documentation gives the check. The replica count set in config.yaml now also reaches the default storage class, so every new volume uses it, not only those created in the Longhorn interface.
The pod network you choose is the one a new cluster gets
The pod network set in config.yaml now decides the pod network of a new cluster, for both Kubernetes and Calico. Earlier versions created every cluster with the same pod network whatever the setting said. An existing cluster keeps the pod network it was created with.
Corrections that reach existing clusters
Two components behaved badly in specific conditions, and both are corrected. metrics-server now reads nodes by address before name, so a cluster whose node names are not in DNS reports node metrics. Fluent Bit’s pods are now ready when Fluent Bit runs, whatever the state of the log destination, so an unreachable destination no longer stops a rolling update or an upgrade. Delivery failures are still reported in the pod log and on Fluent Bit’s health endpoint.
Three settings that no version of their components reads are removed from the configuration BKE applies.
Upgrading
Clusters upgrade from 2.1.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.
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. A setting you have changed yourself is kept. Where your change and BKE’s touch the same setting, the report stops and shows both, so that you decide. The full sequence is in the documentation.