Cloudsoft Spotlight - Your EKS is on extended support

Amazon Elastic Kubernetes Service, commonly abbreviated to simply “EKS”, is AWS’s managed offering of Kubernetes. AWS will manage the Kubernetes control plane for you for a fixed price per hour per cluster. You have to provide the compute resources (a pool of EC2 instances, or configure to use Fargate) and associated storage at your own expense. AWS will provide the management of the Kubernetes control plane, a web console, APIs and EC2 AMIs that simplify the running of Kubernetes (a notoriously complex system to self-manage).

Kubernetes itself has an always-moving release cycle that produces a new Kubernetes release usually three times a year. Each release is supported for security patches and bug fixes for approximately 14 months. Once a version moves out of support, the Kubernetes team will no longer provide updates.

This release cycle is pretty fast by the time scales of many corporation’s application development lifecycles, and you may find yourself struggling to keep Kubernetes up-to-date. As a piece of infrastructure, EKS is generally very stable, and it is easy to forget that each release only gets standard support for just one year.

Realising this, AWS introduced the concept of Extended Support. This takes over when the Kubernetes team ends their standard support for a Kubernetes minor version, and provides an additional year of support. From the AWS announcement:

Amazon EKS versions in extended support receive ongoing security patches for the Kubernetes control plane managed by EKS. Additionally, EKS will release critical patches for the Amazon VPC CNI, kube-proxy, and CoreDNS add-ons, AWS-published EKS Optimized Amazon Machine Images (AMIs) for Amazon Linux, Bottlerocket, Windows, and EKS Fargate nodes. (...) AWS backs all EKS versions in both standard and extended support with full technical support.

This means that when you deploy a new EKS cluster, it will receive security updates and technical support for around 2 years, meaning that you won’t have to worry about this piece of infrastructure for quite some time. The EKS calendar which describes which versions are supported and until when can be found in the EKS documentation.

The Extended Support trap

Extended Support can be a trap, and there are good reasons to want to avoid this as much as possible.

The first and obvious reason is cost. An EKS cluster in standard support costs $0.10 per hour per cluster. The same cluster in extended support costs $0.60 per hour. Put another way, your new EKS cluster will likely cost you $876 in management charges for its first year, and an astonishing $5,256 in its second year.

Now this is just the management charges, and does not include the compute and storage costs. Depending on the size of your application, it may be that the management charge is a relatively small amount and there may be a pragmatic decision to accept the cost. However there is a further consideration which can really leave you feeling trapped.

Even 2 years of support is still less than most application’s lifetimes, so you will have to consider when you are going to upgrade Kubernetes to newer versions (assuming that you don’t want to take the risk of running on an unsupported version.) The only supported upgrade path for Kubernetes is to move one version at a time. If you’re approaching the end of extended support and want to bring yourself up-to-date, that will probably mean 5-6 upgrades. Each upgrade requires:

• Checking the Deprecated API Migration Guide
• Updating the EKS control plane to the newer version
• Updating each managed add-on to the newer version
• Updating each compute nodegroup to use an AMI associated with the newer version
• Testing for regressions

If you have multiple environments (test and production, for instance) then you will need to repeat this process multiple times.

As you can see, this can suddenly turn into a major task. It may even be quicker to simply create new clusters and migrate your workloads to them. This is the “trap” of falling behind on Kubernetes version upgrades, and paying for extended support only locks you harder into the trap.

Conclusion

To know if extended support is right for you, ask these questions:

• What is the expected lifetime of my application? Will it be out of use by the “end of support” date on the EKS release calendar?
• Is the extra cost of extended support right for my budget?
• Do I agree to take on the technical debt of later Kubernetes upgrades?

Unless you know your application is nearing the end of its lifetime, you will almost certainly need to take on Kubernetes version upgrades at some point. In most cases, it is worthwhile to build into your application’s medium- and long-term plan regular Kubernetes version upgrades. Delaying, and “bunching up” upgrades so that multiple versions will need to be done in succession makes the process harder. The more often upgrades are done, the more familiar your team will be with the process and the easier each upgrade will be.

Kubernetes is, at its core, a fast-moving product, and allowing yourself to fall too far behind the newest version creates a significant technical debt. Relying on extended support to give you breathing space and put off Kubernetes upgrades will only make the upgrade process harder when it eventually becomes unavoidable. This is how extended support becomes a trap which can be very hard to escape from.

Cloudsoft Spotlight for AWS

Cloudsoft can scan your AWS accounts, and identify where you are being charged for extended support.

If you have arrived here from the Cloudsoft Spotlight report, we have identified that you have EKS clusters in extended support and could potentially reduce your bill or change your approach.  Please contact Cloudsoft if you need support for this.

This post is part of our Spotlight series, where Cloudsoft experts use advanced tooling to look across your AWS estate for opportunities to optimize cost, increase security and take advantage of the latest innovations in AWS.  We let you focus on your business objectives by ensuring you use AWS effectively.