Kubernetes is giving off good vibes

Kubernetes is the de facto standard when you think about container orchestration and scheduling, automation in software deployment, and maybe even more a whole ecosystem of tools and components orbiting around it.

Since its origin in 2015, Kubernetes has been designed to manage hundreds of thousands of containers. Organized as a cluster, Kubernetes is also able to handle thousands of nodes. In theory, with up to 5000 nodes.

Quick recap on versioning, release cycles, and EOL policy

Like lots of software, Kubernetes follows the X.Y.Z version format, also known as the semantic versioning

• X for the major version
• Y for the minor version
• and Z for the patch version.
  

Even if the first version of Kubernetes came 8 years ago, on July 2015, we are still in major version 1.

The release cycle of Kubernetes is pretty dynamic. Three times a year, roughly, Kubernetes releases a new version. This release marks a change on the minor version, moving from (as of now) 1.Y.Z to 1.Y+1.0. and each such release comes with a set of new features organized in stages. 
As described on the official website, a feature is in the Alpha stage, and then graduated across the different releases to the Beta and Stable stages.

Worth noting, the end-of-life policy is dynamic as well. Kubernetes supports the three last minor versions. Released every 3 to 4 months, a minor version will be so marked EOL after a year or so. This was intentional, to push users to keep an up to date deployment of their cluster.
After this quick recap on versions and how Kubernetes planned the release of their product, let’s move on to an overview of the latest stable version of Kubernetes. The rush is over; time has come to look over how major cloud providers have reacted to the release of this new version.

Kubernetes v1.27: Chill Vibes

Announced on April 11th, the version 1.27 is planned to be EOL in June 2024.
Since its release, the version 1.27.4 is available for download and deployment and so it provided four additional sets of bug fixes.

As always, when a new release is announced, I encourage you to carefully read the release notes from Kubernetes. This should be treated as the source of truth for all upcoming features, breaking changes, and bug fixes. You’ll find in the release notes information related to the 1.27.0 but also all later patch releases!

Availability on major managed Kubernetes

The official release of Kubernetes is for vanilla deployments. That implies that all other providers or vendors of any solution based on Kubernetes would need to ingest any new release into their ecosystem, with, of course, heavy testing. And this may cause some delays. Be aware if you want to proceed with deployment into production, the day following the new release of Kubernetes ! You may be disappointed 😉

Let’s take a look at the major managed Kubernetes offerings and how providers have replicated the availability of the last version.

Azure Kubernetes Service by Microsoft

Sorted by alphabetical order, let’s start with Microsoft and their Azure Kubernetes Service (AKS) offering. Kubernetes is offered to AKS customers across three different sets of release channels: Upstream release (early adopters), AKS preview, and AKS GA. While the 1.26 has been GA since April this year, the 1.27 is planned to be available on AKS in July. At the time of writing, we can see it is still in preview.

Container Engine for Kubernetes from Oracle

Now comes Oracle‘s Container Engine for Kubernetes (OKE). Two release channels, but the status is clear. Since the 1.26 was supported in April, there is no official release date for the 1.27 on OKE, either on the upstream channel or the OKE release channel.

Elastic Kubernetes Service by AWS

The next cloud provider is AWS, with their Elastic Kubernetes Service (EKS). Similar to how Microsoft has organized AKS, AWS is providing two release channels: Upstream release and Amazon EKS release. On the most stable one, the 1.27 has been available since May the 24th.

Google, Google Kubernetes Engine by Google

Third provider, offering managed Kubernetes to their customers, Google with their Google Kubernetes Engine (GKE). Kubernetes is deployed here across three different release channels: rapid, regular and stable. Since the 1.25 is available on the stable release channel, you need to use the rapid one to get the 1.27 with an availability on the stable channel for early July. (here are the links to the release notes and release schedule)

Rancher by Suse

Short edit from the last time I’ve release that blog post. Just adding Rancher, which is a well know managed Kubernetes product from Suse. The last version of Rancher, 2.7.6, released quite recently, the 30th of September, supports Kubernetes 1.26. You can see more details here.

Tanzu Kubernetes Grid by VMware

Lastly, well, this list wasn’t planned to be exhausitve, VMware with Tanzu Kubernetes Grid (TKG).
Announced in mid May this year, the release 2.2 has listed new features and version upgrades.

Unfortunately, nothing about 1.27, even the 1.26. Currently, TKG supports Kubernetes versions 1.25.7, 1.24.11, 1.23.17. And that’s it.

You can see from that brief inventory that managed Kubernetes won’t automatically make available the latest releases of Kubernetes. But that doesn’t take anything away from the quality of each one !

Keep your Kubernetes cluster up-to-date!

With their release cycle and their EOL policy, Kubernetes push users to keep their clusters up-to-date. 

I won’t paraphrase what my colleague Nabil well explained on his blog, or the quite detailed procedure on the official website, but the upgrade process is easy with zero downtime. This is applicable for vanilla Kubernetes deployments only, as when using managed Kubernetes, you are tied to what the provider has organized.

In that specific order, you first upgrade the primary control plane node (aka the primary master), followed by the other control plane nodes, and finally the worker nodes.

Closing thoughts

When we started to work on Kubernetes, accumulated expertise, and built best practices, we came to some conclusions.

Don’t underestimate the importance of patching your cluster. Each new minor or patch version comes with critical bug-fixes. And even if you are not interested in new features, some may have been graduated from one of the early stages, such as Alpha to Beta or Stable. You will experience improvements and stability.
Organize the patching of your cluster, straight with the design of your infrastructure and don’t treat it separately. Think about automation to ease the process and reduce errors to a minimum.

That said, you might encounter some difficulties when it comes the time to implement this theory. You may face some trouble dealing with administrative procedures and constraints on upgrading the cluster. Because even if the upgrade is announced with zero downtime, you may host some critical applications that won’t accept any sort of risk of downtime.

1.27 was announced in April of this year. 1.28.0 is expected to be soon GA on the 15th of August this year. The rapid development of Kubernetes continues, but it has proven its stability and reliability over the past few years!