eksctl is the official CLI for Amazon Elastic Kubernetes Service (EKS). It simplifies the process of creating and managing EKS clusters by automating the underlying AWS resource provisioning.
Let’s see eksctl in action. Imagine you want to spin up a basic EKS cluster named my-cluster in the us-west-2 region with a single node group. Here’s how you’d do it:
eksctl create cluster \
--name my-cluster \
--region us-west-2 \
--nodegroup-name standard-workers \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4
This command does a lot behind the scenes: it creates an EKS control plane, an IAM role for the control plane, a VPC (if one isn’t specified), subnets, security groups, and a managed node group with three t3.medium EC2 instances. The --nodes-min and --nodes-max flags configure autoscaling for your node group.
The real power of eksctl lies in its declarative configuration files. Instead of passing dozens of flags, you can define your cluster’s desired state in a YAML file. This makes your cluster configurations versionable, repeatable, and easier to manage.
Here’s a more advanced example using a configuration file (cluster.yaml):
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: prod-cluster
region: eu-central-1
version: "1.28"
managedNodeGroups:
- name: primary-workers
instanceType: m5.large
desiredCapacity: 3
minSize: 2
maxSize: 5
volumeSize: 100
ssh:
allow: true
publicKeyName: my-ec2-keypair
addons:
- name: vpc-cni
version: latest
resolveConflicts: overwrite
- name: coredns
version: latest
resolveConflicts: overwrite
- name: kube-proxy
version: latest
resolveConflicts: overwrite
To create a cluster with this configuration, you’d run:
eksctl create cluster -f cluster.yaml
This configuration specifies the cluster name, region, Kubernetes version, details for a managed node group (instance type, desired capacity, disk size, SSH access), and explicitly enables and configures core EKS add-ons like vpc-cni, coredns, and kube-proxy. The resolveConflicts: overwrite ensures that even if these add-ons are already present in a default configuration, eksctl will manage them according to this specification.
eksctl handles the complex interactions between AWS services. For instance, when you create a managed node group, eksctl automatically provisions an Auto Scaling Group, launches EC2 instances, joins them to the EKS cluster using a bootstrap script, and configures IAM permissions for the nodes to communicate with the EKS control plane. It also sets up the necessary Kubernetes RBAC roles for the system:node group, allowing nodes to register themselves with the cluster API server.
The mental model for eksctl is that it’s an orchestrator for AWS infrastructure that directly supports EKS. It translates your high-level desires (like "I want a cluster with X nodes of Y type") into specific AWS API calls for EC2, IAM, CloudFormation (often used under the hood), and EKS itself. It abstracts away the boilerplate of creating VPCs, subnets, security groups, IAM roles, and the EKS control plane.
When you delete a cluster using eksctl delete cluster --name my-cluster --region us-west-2, it doesn’t just delete the EKS control plane. It also tears down all the associated resources it created, including the node groups, Auto Scaling Groups, EC2 instances, and often the VPC, depending on how it was configured. This "infrastructure as code" approach, even when managed via a CLI, is crucial for maintaining clean and auditable environments.
One aspect that often surprises people is how eksctl manages Kubernetes versions. When you specify a version in your ClusterConfig and later upgrade it, eksctl orchestrates the control plane upgrade and then guides you through upgrading your node groups. It handles the complex process of draining nodes, replacing them with new instances running the updated Kubernetes version, and ensuring minimal disruption to your running workloads. This is far more involved than just updating a single parameter; it involves careful sequencing and health checks.
The next step after creating and configuring your cluster is typically to deploy applications and manage their lifecycle using Kubernetes manifests, often with tools like Helm or Kustomize.