Amazon EKS — Architecture — Practice Exercises

4 minute read

Chapter 4 — Practice Exercises

Test your EKS architecture knowledge with these 5 exercises.

Exercise 1: Control Plane Components

Question: Name the 4 main control plane components, explain what each does, and explain why AWS runs them across 3 Availability Zones.

Show Solution

The 4 main control plane components:

  1. API Server — The front door to the cluster. Every kubectl command, every kubelet heartbeat, every controller action goes through the API server. It validates and processes REST requests, then stores the result in etcd.

  2. etcd — The cluster’s database. It stores all cluster state: Deployments, Pods, ConfigMaps, Secrets, everything. It’s a distributed key-value store that requires a quorum (majority) of nodes to work.

  3. Scheduler — Watches for newly created pods that have no assigned node, then selects the best node based on resource requests, affinity rules, taints, and tolerations.

  4. Controller Manager — Runs control loops (controllers) that watch the state of the cluster and make changes to move toward the desired state. Examples: ReplicaSet controller ensures the right number of pods are running; Deployment controller manages rollouts.

Why 3 AZs?

  • etcd needs a quorum of 2/3 nodes to write — if one AZ goes down, the other 2 can still form a quorum
  • API server across 3 AZs behind NLB ensures no single point of failure
  • An entire AZ failure (power, network) won’t take down the control plane
  • This is how AWS delivers the 99.95% SLA

Exercise 2: Endpoint Access

Question: Your security team requires that the Kubernetes API is never accessible from the public internet, but your developers need to run kubectl from their laptops. What endpoint configuration and additional infrastructure would you recommend?

Show Solution

Configuration: Private-only endpoint + VPN

vpc:
  clusterEndpoints:
    publicAccess: false
    privateAccess: true

Additional infrastructure needed:

  1. VPN (AWS Client VPN or Site-to-Site VPN)
    • Developers connect via VPN to the VPC
    • kubectl traffic routes through VPN to private ENIs
  2. Alternative: Bastion host
    • EC2 instance in a private subnet with SSM Session Manager
    • Developers SSH tunnel through bastion to reach API server
  3. Alternative: AWS Systems Manager Session Manager
    • No bastion needed — use SSM port forwarding 
      $ aws ssm start-session --target i-xxxx \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["443"],"localPortNumber":["6443"]}'

Trade-offs:

  • More secure (no public API access)
  • More complex (VPN setup, developer onboarding)
  • Small latency increase (VPN hop)

Exercise 3: VPC Sizing

Question: You’re designing a VPC for an EKS cluster that will have 50 nodes, each running up to 30 pods. Calculate the minimum subnet size needed for private subnets, and explain your recommendation.

Show Solution

Calculation:

Nodes: 50
Pods per node: 30
Node IPs: 50
Pod IPs: 50 × 30 = 1,500
Total IPs needed: 50 + 1,500 = 1,550
Buffer (2x for growth): 3,100

Subnet size needed per AZ (3 AZs):
3,100 ÷ 3 = ~1,034 IPs per AZ

Minimum: /22 (1,024 IPs) per AZ — barely enough!

Recommended: /19 (8,192 IPs) per AZ — allows for growth, VPC CNI prefix delegation, and IP warm pool.

Why larger is better:

  • VPC CNI pre-allocates IPs (warm pool) which consumes extra
  • Prefix delegation mode allocates /28 blocks (16 IPs at a time)
  • Pod churn (rolling updates) temporarily needs old + new pod IPs
  • Future growth — adding nodes is easy, resizing subnets is hard

Exercise 4: Data Plane Selection

Question: Design the data plane for an e-commerce platform with: web frontend (steady traffic), order processing (bursty), ML recommendation engine (GPU), and nightly batch jobs. Specify the node group type, instance type, and scaling strategy for each.

Show Solution 
managedNodeGroups:
  # Web frontend — steady, cost-optimized
  - name: frontend
    instanceTypes: [m5.large, m5a.large, m4.large]
    desiredCapacity: 3
    minSize: 3
    maxSize: 10
    spot: false          # On-Demand for reliability
    labels:
      workload: frontend

  # Order processing — bursty
  - name: processing
    instanceTypes: [c5.xlarge, c5a.xlarge]
    desiredCapacity: 2
    minSize: 1
    maxSize: 20
    spot: true           # Spot OK (with retries)
    labels:
      workload: processing

  # ML recommendations — GPU
  - name: gpu
    instanceType: g4dn.xlarge
    desiredCapacity: 1
    minSize: 0
    maxSize: 4
    spot: false          # On-Demand (GPU Spot is unreliable)
    labels:
      workload: ml
    taints:
      - key: nvidia.com/gpu
        value: "true"
        effect: NoSchedule

# Batch jobs — serverless
fargateProfiles:
  - name: batch
    selectors:
      - namespace: batch
        labels:
          workload: batch

Reasoning:

  • Frontend: On-Demand for reliability, mixed instances for availability
  • Processing: Spot for cost savings, high max for burst
  • GPU: Dedicated with taint to prevent non-GPU workloads
  • Batch: Fargate — pays per pod-second, no idle nodes

Exercise 5: Version Upgrade Plan

Question: Your production EKS cluster is running Kubernetes 1.27 (now in extended support). Create a step-by-step upgrade plan to get to 1.29. Include the order of operations, testing strategy, and rollback plan.

Show Solution

Upgrade Plan: 1.27 → 1.28 → 1.29

Phase 1: Preparation

  1. Review K8s 1.28 and 1.29 changelogs for breaking changes
  2. Check add-on compatibility (VPC CNI, CoreDNS, kube-proxy)
  3. Review deprecated APIs using kubectl deprecations or Pluto tool
  4. Test in staging environment first

Phase 2: Upgrade to 1.28

# Step 1: Update add-ons
$ aws eks update-addon --name vpc-cni --cluster-name prod --resolve-conflicts OVERWRITE
$ aws eks update-addon --name coredns --cluster-name prod
$ aws eks update-addon --name kube-proxy --cluster-name prod

# Step 2: Upgrade control plane
$ aws eks update-cluster-version --name prod --kubernetes-version 1.28
# Wait 15-30 minutes

# Step 3: Upgrade node groups (one at a time)
$ eksctl upgrade nodegroup --name general --cluster prod --kubernetes-version 1.28
# Wait for rolling update to complete

# Step 4: Verify
$ kubectl get nodes   # All should be 1.28
$ kubectl get pods -A # All should be Running

Phase 3: Upgrade to 1.29 Repeat Phase 2 steps with version 1.29.

Rollback plan:

  • Control plane: Cannot roll back (forward-only)
  • Node groups: Launch a new node group with old version, drain old nodes
  • Applications: Revert deployments with kubectl rollout undo
  • Ultimate fallback: Restore from cluster backup (eksctl or Velero)

Cost savings: Moving from 1.27 extended to 1.29 standard saves $365/month per cluster.

What’s Next?

Deep dive into compute options: Chapter 5 — Node Groups.

You may also enjoy