AWS will offer extended support for Kubernetes versions in its Amazon EKS Anywhere proposition, with security patches for clusters on Kubernetes version for up to 26 months after the version is released.
EKS Anywhere is a proposition for those wanting to run Kubernetes clusters using EKS software on-premises; typically on their own hardware (bare metal, CloudStack, Nutanix, Snowball Edge, vSphere, are the options for compute; Bottlerocket, RHEL and Ubuntu the options for node OS.)
“Cluster administrators and security teams… now get more time to plan Kubernetes upgrades, without compromising on the security posture of their clusters,” AWS said. (Standard support begins when a Kubernetes version becomes available in Amazon EKS Anywhere, and continues for 14 months. The extended support adds a further 12 months, AWS said.)
Extended support for Kubernetes: 12 years?
The extension offer follows Ubuntu-maintainer Canonical’s decision in February to offer a Long Term Support (LTS) package for Kubernetes that will “support FedRAMP compliance and receive at least 12 years of committed security maintenance and enterprise support on bare metal, public clouds, OpenStack, Canonical MicroCloud and VMware.”
That was warmly welcomed by many in the community. As one Head of Engineering, Rob Dyke, told The Stack: “Maintaining stable and secure platforms is critical. I have an environment of ‘nailed-up’ services – essential workloads running on older, but functional, components.
Join peers following The Stack on LinkedIn
“Forced upgrades, often required by short support windows, pose significant risks to these services. Canonical's 12-year LTS commitment for Kubernetes and Docker images directly addresses this challenge. It provides the stability needed to maintain these critical workloads without the constant pressure and risk of disruptive updates,” he added.
Dyke concluded: “This extended support window allows my engineering teams to focus on innovation rather than reactive maintenance. I'll take that and bring my own cloud over Microsoft's AKS offering. I think that LTS Everything will help strengthen our security and compliance posture…
A reduced upgrade frequency minimizes downtime and associated expenses. I want my engineering teams to focus on strategic projects and new feature development, driving business growth and maximizing ROI.”
Multi-tenant K8 clusters get tricky...
Chetan Shivashankar, Kubernetes Tech Lead at Percona told The Stack that there’s really no fixed timeline in most organisations for Kubernetes update cycles: “It varies across industries, and within companies in the same industry too... There are reasons for delaying upgrades - for example, many applications use the API for k8s to manage their environments and applications which makes it a tight coupling between the application and the k8s version.
“Sometimes, these APIs may be deprecated or totally removed during a k8s upgrade, which then breaks the overall application. Unless the application itself is upgraded, the version of k8s running cannot be upgraded. With a multi tenant k8s cluster, this challenge amplifies even further. The k8s cycle is fast, with approximately three releases per year and sometimes this is too quick for some business."
See also: A NASDAQ-listed firm left its K8s clusters perilously exposed. 1,000+ have fallen into the same trap. Here’s why
He added: "The most important thing the user has to check is if there are any API used by their applications or add-ons which can potentially break with the k8s upgrade. In practice, the user has to properly check the release notes, evaluate potential issues and of course test it in a non production environment.
In a production environment, the API Server might observe minor glitches. The kubernetes nodes are recycled to have the new version of nodes running and the pods will be recreated. To check the impact of the update, application behaviour needs to be evaluated to check that those services are running as expected. Any potential issues like downtime, maintenance windows should be addressed before upgrading the cluster.
"One often neglected part of the upgrade is the disaster recovery plan. What happens when an upgrade fails? Some of the k8s distributions that are available, like the ones provided by cloud service providers, do not provide the ability to roll back to previous k8s versions, so if the move doesn’t work out as you expect then you can be in more trouble than you expected. To manage this, a proper DR plan needs to be put in place before the upgrade."
In other Kubernetes news... K8s-native security scanner Kubescape has officially entered the CNCF Incubating stage. The project, first created by Ben Hirschberg, CTO of ARMO, is an an open-source Kubernetes security platform for your IDE, CI/CD pipelines, and clusters. It includes risk analysis, security, compliance, and misconfiguration scanning."
It's on GitHub here under an Apache 2.0 licence.
