Bahriya Kubernetes Engine 2.1.0 is released. It is a minor release: it moves the Kubernetes patch, the container runtime, Calico and every bundled component to its latest compatible release, and it leaves the Kubernetes minor where it is. Exact versions, every one pinned to a patch, are in the release notes in the Mamluk Console.
Under BKE’s release rules a minor may drain nodes, and this one does: the Kubernetes patch, the container runtime and Calico each restart something on every node. Plan it as a maintenance window.
Every component, brought up to date
All seven bundled components move in this release: metrics-server, cert-manager, Longhorn, Kong, Kuma, Fluent Bit and Netdata. Calico and cert-manager both return to versions that their maintainers test on the Kubernetes minor BKE runs.
Longhorn moves one minor. Longhorn can only be upgraded one minor at a time, so every cluster must take this step before a later release can move Longhorn again. Longhorn’s new version also introduces network policies for its own internal components and enables them by default. BKE 2.1.0 turns them off, so the upgrade does not change how Longhorn’s traffic flows; a later release will enable them once they have been tested on clusters built by BKE.
The new software checks your configuration first
A new version of a component can refuse a configuration that the previous version accepted. When that happens, the configuration is the same before and after the upgrade, so no comparison of values can show the problem. The only reliable answer comes from the new software itself.
So before an upgrade reports, BKE now runs each component that will change against the configuration it would receive. Each check runs the new image, on your own node, in a container with no network. BKE also confirms that every image exists and that the Kubernetes API server accepts every object, in a dry run that stores nothing. A configuration the new version refuses stops the upgrade before anything is applied, with the software’s own error printed beneath it.
Settings your configuration holds back
Two things can keep a setting where it is without any line of your configuration changing. A value written as the old chart’s default stays at that value when the new chart’s default moves. A setting BKE applies to every cluster, missing from your file, leaves the chart’s own default in its place. The upgrade report now lists both, so that a component upgraded on paper is not left running old software in practice.
Before you upgrade
In the Calico version 2.1.0 pins, AdminNetworkPolicy and BaselineAdminNetworkPolicy are no longer enforced; ClusterNetworkPolicy replaces both. Existing resources of either kind stay in the cluster and nothing reports an error, but they stop taking effect. If you use either, replace each with an equivalent ClusterNetworkPolicy before upgrading. The release notes list this and the cert-manager changes that can reach your own resources, with the command that shows whether any apply to you.
Existing customers upgrade from 2.0.x in the usual order: upgrade.sh on each node in turn, then apply.sh for the components, reading the report before committing it. The full sequence is in the documentation.