EKS Kubernetes version deprecation

[xose]

On July 22, 2019 all EKS 1.10 clusters will be automatically updated to 1.11. A similar process will happen in the future for other Kubernetes versions, with AWS giving a 60 day warning before a deprecation and forced update.

https://aws.amazon.com/blogs/compute/updates-to-amazon-eks-version-lifecycle/
https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html

[0xdabbad00]

Thanks @xose!

[mhausenblas]

Hey, I'm interested to learn why this is considered to be a breaking change. We tried very hard in the referenced blog post and the docs to explain what is happening. Can either @xose or @0xdabbad00 please elaborate what they think is breaking?

[QuinnyPig]

"If you don't update what's running your stuff will break" is sorta the message here. While it's well articulated and a very reasonable policy to take, it's still a breaking change.

[xose]

It's "breaking" just like other similar changes (deprecated runtimes for Lambda, etc.) that could cause your already stablished workflow to stop working.

For example if I had a script that uses the awscli to launch a cluster, or a CloudFormation/Terraform template, and they hardcode the 1.10 version, then they will stop working on that day. Same thing if I depend on some quirk of a particular version of the cluster and it gets updated (we don't use EKS so I don't know how well it handles forward/backward compatibility)

IMO it's a good thing to deprecate old versions, and the blog post does a great job at explaining the changes, why they are happening, and gives a very reasonable timeframe for this deprecation and all future ones. But it's still a breaking change, and this repo is to keep track of all breaking changes in a single place.

[mhausenblas]

Thank you both so much for your explanation. I suppose we can discuss the definition of what breaking changes mean until the cows come home and not reach an agreement, for example, "hardcode the 1.10 version," I would consider a bad practice, it is your repository so you get to make the rules and all we can do is play by these rules and try to implement ways to help folks not to be effected by changes (in general) in a negative way, as much as possible.

Keeping vendors and service providers honest and being vocal about user impact is one of the few under-appreciated and yet most useful things one can spend cycles on. Not many people seem to be willing to do that.

So, keep it coming and thanks for doing this, you're making also my job easier ;)

[0xdabbad00]

@mhausenblas This project started out primarily as a result of the S3 path change that was going to happen that was going to actually break many people's use cases, along with the poor communication by AWS for that change by using a forum post that few people see (https://forums.aws.amazon.com/ann.jspa?annID=6776). That announcement had happened shortly after an announced change to CloudFront that would deprecate API calls made with versions of the API prior to 2016 (https://forums.aws.amazon.com/ann.jspa?annID=6754). Both of those I felt were handled poorly by AWS in terms of their impact and communication, and with the CloudFront issue, the aggressive time table (announced only a month before it was going to take effect!). The result was the need to create this repo to help people stay aware of these changes that very likely could break things in their environment. The CloudHSM change to terminate older Luna instances and the MTurk API deprecations are also changes I can easily argue are "breaking changes".

This repo has since become less conservative in what changes are regarded as "breaking". This Kubernetes change and the Lambda change to update their underlying OS to Amazon Linux 2018.03 are two changes I don't hold a strong opinion about with regard to including them here. What swayed me toward their inclusion is that the update is forced and has a set date. I recognize AWS changes things all the time that potentially could break things, but in these cases, AWS decided to set a timeline and make an announcement for them. This is awesome for AWS to do as it helps ensure customers can perform testing and make the upgrades on their own schedules.

Please do not assume that inclusion of these items in this list is to shame the services! (Except S3's path change). I maintain this repo mostly to have an consolidated list of "potentially" breaking changes with their associated dates so customers can prepare in advance for the change and if something breaks in their environment one day, they might be able to debug the issue faster by checking this list to see if anything changed that day.

Thank you for taking the time to inform customers about these changes and communicate them through a variety of mediums. This repo should be thought of as just another medium to communicate those changes.

I apologize for the name of the repo sounding more aggressive, but again, it was a result of what I view as mishandling by AWS of some changes. I'd be more than happy to retire this repo if AWS would provide something similar (ie. a consolidated list with an RSS feed or other change notification) and would retire using the AWS forums for announcements.

[benmontour-wf]

I think @0xdabbad00 summed up his repo here perfectly above. I wouldn't consider a change being posted here as a negative but rather I consider this as a centralized source for customers to gain information about upcoming changes. It's nice to have it all in one place for easy reference as to what's changing and when. With regards to the EKS change specifically I don't see it as a negative at all. Rather I see it as a chance for customers to be aware of the change and make sure that they will not break anything when the necessary upgrade in versions does happen.