Mastering Kubernetes on Amazon EKS
Provisioning and Architecture
Provisioning with Code
Moving from Kubernetes theory to a running cluster means making concrete architectural decisions. The best way to capture these decisions is with code. While you can click through the AWS console to create an Amazon EKS cluster, this approach is slow, error-prone, and impossible to replicate consistently. Instead, we use tools that turn infrastructure into code.
The official command-line tool for EKS is , a powerful utility that automates cluster provisioning. Instead of issuing a long string of commands, you define your entire cluster in a single YAML file called a ClusterConfig. This declarative approach ensures your infrastructure is version-controlled, auditable, and easily reproducible across different environments.
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: prod-cluster-1
region: us-east-1
version: "1.29"
# Configure cluster-wide networking and logging
vpc:
clusterEndpoints:
publicAccess: true
privateAccess: true
cloudWatch:
clusterLogging:
enableTypes: ["api", "audit", "authenticator", "controllerManager", "scheduler"]
# Define a managed node group using EC2 instances
managedNodeGroups:
- name: general-purpose-x86
instanceType: m5.large
minSize: 2
maxSize: 5
desiredCapacity: 3
availabilityZones: ["us-east-1a", "us-east-1b"]
iam:
withAddonPolicies:
autoScaler: true
ebs: true
This configuration file defines everything from the Kubernetes version and region to VPC endpoint access and control plane logging. It also specifies a managed node group, which is a set of EC2 instances that will run your application containers. This single file is your cluster's blueprint.
EC2 Nodes vs. Fargate
Your EKS control plane is fully managed by AWS, but you have to choose how to run your workloads on the data plane. The two primary options are EC2 Managed Node Groups and AWS Fargate.
Think of it as choosing between owning a custom-tuned car (EC2) versus using a ride-sharing service (Fargate). One gives you total control and performance, while the other offers convenience and abstracts away the maintenance.
EC2 Managed Node Groups give you a fleet of virtual servers that you control. This is the traditional approach. It offers maximum flexibility for performance tuning, lets you use specialized instance types (like those with GPUs), and is required for running DaemonSets, which place a pod on every node for tasks like logging or monitoring.
AWS Fargate is the serverless option. With Fargate, you don't manage any servers. You define a profile, and when you deploy a pod that matches it, AWS provisions the exact compute resources needed, just for that pod. This simplifies operations significantly, as you no longer need to worry about patching, scaling, or securing the underlying nodes. The trade-off is less control and potentially higher costs for steady, long-running workloads.
| Feature | EC2 Managed Node Group | AWS Fargate |
|---|---|---|
| Control | High (choose instance type, AMI, OS) | Low (abstracted away) |
| Use Case | Stateful apps, performance-critical workloads | Microservices, batch jobs, stateless apps |
| DaemonSets | Supported | Not supported |
| Cost Model | Pay for running EC2 instances | Pay per-pod vCPU and memory |
| Operations | Node patching, scaling, security | No node management required |
You can even mix and match. A common pattern is to use Fargate for stateless web applications while running a stateful database or a monitoring agent on an EC2 node group, all within the same cluster.
Building for Resilience
A production-grade cluster must be resilient to failure. The fundamental way to achieve this in AWS is by distributing resources across multiple Availability Zones (AZs). An AZ is one or more discrete data centers with redundant power, networking, and cooling. By spreading your nodes across several AZs, your application can survive an outage affecting a single data center.
Another architectural choice is the CPU. For years, x86 processors from Intel and AMD were the default. Now, AWS offers its own ARM-based [{
Finally, consider the cluster's network access. The Kubernetes API server can have a public endpoint, a private endpoint, or both. A public endpoint is accessible from the internet, which is convenient for development and management from your local machine. A private endpoint is only accessible from within your VPC. For production environments, it is best practice to disable public access and interact with the cluster via a bastion host or VPN connection inside the VPC, drastically reducing its attack surface.
What is the primary benefit of using eksctl with a ClusterConfig YAML file to create an Amazon EKS cluster?
A team needs to deploy a logging agent as a DaemonSet to ensure it runs on every node in their EKS cluster. Which data plane option must they use?
Architecting an EKS cluster involves balancing convenience, cost, and security. Using eksctl with a declarative YAML file makes these decisions repeatable and transparent.