The history of Kubernetes, AWS and EKS

Originally, Amazon Web Services (AWS) didn’t natively support Kubernetes. Amazon for a long while have been trying to push their own docker deployment technology, Elastic Container Service (ECS) instead. Any experienced AWS implementers would have war stories of its repeated shortcomings and the amount of oft-repeated effort migrating clients off of ECS.

Although AWS continues to try to improve ECS, it pales in comparison to what Kubernetes can do. Many engineers saw this, and the open-source community kicked into gear and authored the tool “KOPS” which makes creating a highly-available Kubernetes cluster on Amazon trivial, instead of a complex task.

Amazon realized they weren’t going to win the war of attrition, and implemented their fully managed Kubernetes support service – Elastic Kubernetes Service (EKS). Implementers like myself adopted EKS using the Infrastructure as Code (IaC) tools we know and love to automate AWS.

We quickly learned that Kubernetes is not something you can just automate from the “outside”. There was a gap in what IaC tools alone could (and couldn’t) do in order to reliably upgrade, update, rotate nodes, and manage a Kubernetes cluster. The missing component here was that they needed to “also” manage Kubernetes – to speak to the Kubernetes API and to check, verify, update, delete, and manage things inside of its API, not just give it more resources (eg: add nodes) via the AWS APIs from the outside. Enter EKSCTL.