.png)
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!
Creating 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:
Try to look at the nodes:
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-managed 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.
.png)
