We love EKS!

If you're running on AWS - the best, most hassle-free option of getting a Kubernetes cluster is by using EKS - the Elastic Kubernetes Service. The control plane of EKS clusters is fully managed by AWS while the data plane - i.e. the worker nodes can be defined and managed by the user in various available configurations.

As with anything in modern cloud services - there are a number of ways we can create and manage EKS clusters. Organizations only starting with building out their delivery platform need to choose the provisioning and managing method. This choice has a significant impact on their platform evolution. Often the criteria for making this choice isn't clear.

In this series I intend to give an overview of all the different options and provide a rundown of the benefits and downsides of each method.

And here's our list:

Way 1 - Create an EKS Cluster in AWS Management Console

Way 2 - Create an EKS Cluster in AWS cli

Way 3 - Create an EKS Cluster with eksctl

Way 4 - Create an EKS Cluster with CloudFormation

Way 5 - Create an EKS Cluster with python and boto3

Way 6 - Create an EKS Cluster with AWS CDK

Way 7 - Create an EKS Cluster with Terraform

Way 8 - Create an EKS Cluster with Pulumi

Way 9 - Create an EKS Cluster with Crossplane

In fact - the first 3 ways listed here (Management console, eksctl and aws cli) are all laid out in this AWS guide, so I won't go into too much technical detail. But some things are still worth noting.

So, without further ado - let's start!

Way 1 - Create an EKS Cluster in AWS Management Console

So the fastest, most straightforward way of provisioning any AWS service is of course by going to the console and clicking your way through. No need to install anything on your computer, no need to learn new tools and languages.

And it's actually so easy! Just go to your AWS Management Console, find EKS in the list of available services and proceed to "Add Cluster -> Create":

Right? Wrong!
In fact - before clicking your way to a cluster you need to:

a) Create a VPC and subnets that meet Amazon EKS requirements.
b) Create a Cluster Role in AWS IAM by following this guide.

And then you can click your way through!

On choosing the Kubernetes version

This is something we need to consider for all the methods listed. Unless some specific limitation prevents you - always choose the latest version (currently it's 1.29). AWS make sure to test the version they provide and regularly deprecate older versions. Each Kubernetes version gets 14 months of standard support and upgrading your production cluster can get nerve-wrecking and time-consuming. So again - make sure to always choose the latest one.

A note on observability

The third screen you need to click through when creating EKS from the console is the Observability one. This currently allows you to enable EKS monitoring using Amazon Managed Service for Prometheus.

You only need this if you're not using a 3rd party observability service (like DataDog or NewRelic) - because all of them support monitoring EKS today and you can then set this up at a later stage.

Creating some nodes

After you've successfully clicked through, waited a while and finally saw the cluster state in the console change from "Creating" to "Active" - it's time to connect to the control plane from your kubectl client.

That's where you'll need the AWS CLI, even if you've used the console for everything else until now. Get the kubeconfig:

aws eks update-kubeconfig --name mycluster --region eu-central-1

Added new context arn:aws:eks:eu-central-1:XXXXXXXXXXX:cluster/mycluster to /Users/antweiss/.kube/config

Try to look at the nodes:

(⎈ | mycluster:default)➜  kubectl get node
No resources found

And that's where we realize we still need to create the nodes!
This can be done by going to EKS->Clusters->mycluster->Compute and choosing either to use self-manged nodes, create a managed Node Group or utilize a Fargate Profile.

What option to use for your EKS nodes is a topic for a whole separate post. I won't go into it here. You can consult this page for a basic comparison of all these options. OR drop me a note in comments if you'd like my advice.

Provisioning EKS from the Management Console - the Bottom Line

As we saw in this post - the manual method is kinda straightforward, but it still leaves a lot of detail for us to take care of.
In addition - this method doesn't scale well. It can work ok for a couple of small clusters but once we are in production - running at scale, across multiple geographical regions - managing things by hand becomes too slow and error prone. Professional platform engineers manage their infrastructure as code.
And that will be shown in the upcoming installments of this series.

Subscribe for updates and leave your comments if there's anything unclear or plain wrong! ;)