🔧 Module 03 — Building & Maintaining an Amazon EKS Cluster

1. AWS Console — guided wizard, not repeatable
2. AWS CLI — aws eks create-cluster, scriptable but verbose
3. eksctl — purpose-built CLI, creates VPC + IAM + cluster in one command

The Console is not repeatable — it produces no code artifact. If you need to recreate the cluster (DR, new region, staging env), you have to click through the wizard again. Use eksctl or IaC for any cluster you care about.

eksctl automatically creates:
• VPC (192.168.0.0/16) with public/private subnets
• IAM roles for the cluster and node group
• CloudFormation stacks to manage all resources
• kubeconfig entry on your local machine
The AWS CLI only calls the EKS API — you supply all dependencies.

1. IAM roles for cluster + node group
2. Dedicated VPC (192.168.0.0/16) with public & private subnets
3. EKS cluster (control plane)
4. Managed node group with specified instance type
5. API endpoint access configuration
6. kubeconfig written locally for kubectl

192.168.0.0/16 — eksctl's default VPC CIDR. This avoids conflicts with the common 10.0.0.0/8 and 172.16.0.0/12 ranges used in corporate networks. You can override this in cluster.yaml via the vpc.cidr field.

The --managed flag creates a managed node group instead of a self-managed one. With a managed node group, EKS handles rolling updates, AMI patching, and draining — you don't manage the lifecycle yourself. It's almost always the right choice for new clusters.

It deploys node group instances into private subnets only — nodes get no public IP addresses. Traffic between nodes and the internet routes through a NAT Gateway. This is a security best practice for production clusters.

B. The --region flag on the CLI command:
eksctl create cluster --region us-west-2

C. The metadata.region field in cluster.yaml:
metadata:
  region: us-east-1

AWS CloudFormation. eksctl generates and submits CloudFormation stacks for every resource it creates (VPC, EKS cluster, node group). This means all eksctl-created resources appear in the CloudFormation console and benefit from stack-level rollback.

Bottlerocket — an open-source Linux-based OS developed by AWS. It contains only what is needed to run containers, resulting in a minimal attack surface and faster startup. Available as a built-in EKS AMI option.

Amazon EKS Optimized Linux is the default. "Turnkey" means AWS pre-installs and pre-configures all EKS node components (kubelet, kube-proxy, containerd, AWS VPC CNI) — you select it and it works immediately with no additional setup.

AWS Fargate. Fargate is serverless — AWS manages the underlying compute. You cannot bring a custom AMI because there is no node OS for you to control. Custom AMIs are only valid for EC2-based node groups (self-managed or managed).

Windows Server 2019 and Windows Server 2022. EKS supports mixed Linux/Windows clusters — you can have Linux node groups and Windows node groups in the same cluster. Pod scheduling to the right OS is handled with node selectors.

Security: Smaller OS footprint = smaller attack surface
Immutability: The OS is read-only at runtime (harder to persist malware)
Automatic updates: Atomic OS updates with rollback support
Purpose-built: No general-purpose packages, only what containers need

EKS Blueprints are pre-built cluster templates that include not just the EKS cluster but also operational software — cluster autoscaler, load balancer controller, metrics server, logging, etc. You get a fully bootstrapped cluster ready for production workloads, not just raw infrastructure.

Automatic rollback on failure. If a CloudFormation stack update fails, AWS automatically rolls back all changes to the previous known-good state. Other benefits: native AWS integration, change sets for previewing updates, drift detection.

Multi-cloud: Terraform manages AWS, GCP, Azure resources in a single codebase
Existing workflows: Teams already using Terraform for other infra don't need a second tool
State management: Terraform state file supports complex dependency tracking across providers
Community modules: Rich ecosystem of EKS modules on Terraform Registry

Control plane first, data plane second. Always upgrade the EKS control plane before upgrading worker nodes. The Kubernetes compatibility guarantee says a control plane can be one minor version ahead of nodes, but not the reverse.

AWS applies patch versions automatically to the control plane (e.g., 1.27.1 → 1.27.4). You only control minor version upgrades (e.g., 1.27 → 1.28). This is one of the managed benefits — you never need to apply a patch for the API server.

B — Minor version upgrade (e.g., 1.26 → 1.27). Only major or minor version upgrades can remove or change APIs. Patch versions (1.27.1 → 1.27.2) never remove APIs. This is why step 3 (identify API changes) only matters for minor version upgrades.

AWS Fargate. Because Fargate is serverless and AWS manages the underlying compute, Fargate nodes are automatically upgraded when new Pods are scheduled. There is no node upgrade action required from you for Fargate workloads.

EKS automatically rolls back the control plane. New API server nodes are deployed alongside old ones; only after the new nodes are healthy does EKS cut over. If health checks fail, the rollback is automatic and the cluster stays on the original version.

Add-ons like CoreDNS, kube-proxy, and VPC CNI have version compatibility requirements tied to the Kubernetes minor version. An old add-on version may not support new API objects introduced in the upgraded Kubernetes version — upgrading add-ons after the control plane ensures compatibility.

Via the AWS Console or eksctl:
eksctl upgrade nodegroup \
  --name=standard-workers \
  --cluster=prod \
  --kubernetes-version=1.28

EKS performs a rolling update: new nodes → drain old nodes → terminate old nodes.

✓ B — Bottlerocket

Bottlerocket is the open-source, container-specific OS developed by AWS. EKS Optimized Linux (A) is the default/turnkey option but not specifically container-only. Custom (C) and Windows (D) serve different purposes.

✓ B and D

B. kubelet on each node — uses the node IAM role to make EC2, ECR, and CloudWatch API calls.
D. Applications running in pods — pods inherit the node IAM role unless IRSA (IAM Roles for Service Accounts) is configured. The API server (A) and scheduler (C) run in the AWS-managed control plane, not on your nodes.

✓ B and C

B. --region flag — e.g. eksctl create cluster --region us-west-2
C. cluster.yaml — metadata.region: us-east-1

AWS_DEFAULT_REGION (A) works with the AWS CLI but is not the eksctl-specific method. IAM role ARN (D) is for authentication, not region selection.

✓ B — Minor version upgrade

Kubernetes follows semver: only minor version upgrades (e.g. 1.27 → 1.28) can deprecate and remove APIs. Patch versions (A) are backward-compatible bug fixes. Major versions (C) would also remove APIs but EKS doesn't ship major K8s changes independently. AMI updates (D) don't change the Kubernetes API.

192.168.0.0/16 — eksctl's built-in default VPC CIDR. It also creates subnets across two AZs and configures both public and private subnets. You can override this with vpc.cidr in cluster.yaml.

Step 5 is "Upgrade the cluster control plane". EKS deploys new API server nodes alongside old ones, waits for them to be healthy, then cuts over. If new nodes fail health checks, EKS automatically rolls back to the old nodes — no manual intervention needed.