Kubernetes versions and upgrades

Overview

Cloudfleet upgrades your clusters for you. Cloudfleet upgrades clusters frequently to add new features while the underlying Kubernetes version stays the same. We call these versions CFKE patch versions. When your cluster upgrades to a new CFKE patch version, the underlying Kubernetes version usually stays the same.

Less frequently, we also upgrade the Kubernetes version along with the CFKE Patch Version.

A minor version of Cloudfleet Kubernetes Engine (CFKE) supports all Kubernetes versions that upstream officially supported at the time of its release. For more information on the upstream support policy, see the Version Skew Policy. Over time, new CFKE patch versions add support for updated Kubernetes patch versions and phase out older ones, particularly if critical bugs affect them.

CFKE generally removes support for Kubernetes minor versions when they reach end-of-life (EOL). An exception is possible if upgrading to a newer Kubernetes version needs significant migration effort, such as handling deprecated API versions. In such cases, CFKE may offer limited support for an EOL version for one more release cycle. This gives you time to complete the migrations.

Release channels

A cluster’s release channel controls how quickly its control plane adopts new Kubernetes and CFKE releases. The channel applies to the control plane Kubernetes API and kubelet versions. When you pick a more relaxed channel, Cloudfleet moves the cluster to newer versions automatically as they become available on that channel. You get a predictable update cadence without manual work.

Three channels are available:

• rapid (default): receives new releases first. The cluster gets the latest Kubernetes and CFKE features and fixes as soon as they ship. Available on all tiers.
• stable: balances freshness with stability. It adopts releases after they mature on rapid. Requires the Pro or Enterprise tier.
• extended: stays on a given release the longest, so the version changes least often. Requires the Enterprise tier.

Basic clusters always use the rapid channel. To move to stable or extended, upgrade the cluster to Pro or Enterprise. See Cluster types for what each tier includes.

You can set the release channel when you create a cluster. You can change it later from the Cloudfleet Console, the CLI, or the Terraform provider. All channels use the same non-disruptive upgrade process, described below. The control plane gets a rolling update. Your existing compute nodes stay untouched until they are replaced.

Frequently asked questions

Q: Can I access my cluster while the control plane is upgrading?

Yes. The control plane upgrades with a rolling update strategy, so it stays available during the whole upgrade.

Q: How can I ensure that cluster upgrades do not disrupt my workloads?

Currently, we do not upgrade your compute nodes automatically. We first upgrade the control plane and leave your compute nodes untouched. If a node is deleted and recreated, the new node gets the updated control plane version. With this approach, your workloads stay available and unaffected during and after the cluster upgrade.

If you want to upgrade your nodes proactively (for various reasons) instead of waiting for the node auto-provisioner to replace them, drain the nodes individually. Draining creates new nodes with the updated version and then deletes the old ones.

Q: How do I upgrade self-managed nodes?

To upgrade a self-managed node, re-add it to the cluster. Re-adding synchronizes the node with the current control plane version. We plan to automate this process in the near future.