EKS

EKS splits Kubernetes into a managed control plane (run by AWS) and a data plane (your worker nodes). Understanding this split is essential for troubleshooting and cost management.

The control plane communicates with worker nodes via the Kubernetes API. Worker nodes run the kubelet, kube-proxy, and container runtime (containerd).

EKS offers three ways to run worker nodes. Each has different trade-offs in operational overhead, flexibility, and cost.

Fargate profiles use label selectors to determine which pods run on Fargate. Any pod matching the namespace and label selector runs serverlessly.

# Create a Fargate profile
aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name my-profile \
  --pod-execution-role-arn arn:aws:iam::123:role/eks-fargate-role \
  --subnets subnet-abc subnet-def \
  --selectors namespace=production,labels={app=api}

EKS uses the Amazon VPC CNI plugin by default, which assigns real VPC IP addresses to pods. Each pod gets a secondary IP from the node's ENIs. This is fundamentally different from most Kubernetes CNIs that use overlay networks.

The number of pods per node is limited by the instance's ENI count and secondary IPs per ENI. A t3.medium supports 3 ENIs x 6 IPs = 17 pods max (subtract 1 per ENI for the primary IP).

# Check max pods for an instance type
aws ec2 describe-instance-types \
  --instance-types t3.medium \
  --query "InstanceTypes[0].NetworkInfo.{MaxENI:MaximumNetworkInterfaces,IPv4PerENI:Ipv4AddressesPerInterface}"

# Enable prefix delegation to increase pod density
# (assigns /28 CIDR blocks instead of single IPs)
kubectl set env daemonset aws-node \
  -n kube-system \
  ENABLE_PREFIX_DELEGATION=true

EKS maps AWS IAM identities to Kubernetes RBAC using the aws-auth ConfigMap. IAM Roles for Service Accounts (IRSA) lets pods assume IAM roles via OIDC federation - the correct way to give pods AWS API access.

# 1. Associate OIDC provider with cluster
eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster --approve

# 2. Create IAM role with IRSA trust policy
eksctl create iamserviceaccount \
  --cluster my-cluster \
  --namespace production \
  --name my-app-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve

# 3. Reference in pod spec
# spec:
#   serviceAccountName: my-app-sa

EKS workload scaling has two levels: pod scaling (HPA, VPA, KEDA) and node scaling (Cluster Autoscaler, Karpenter). Karpenter is the modern replacement for Cluster Autoscaler on EKS.

Karpenter is faster than Cluster Autoscaler (seconds vs minutes) because it calls EC2 APIs directly instead of adjusting ASG desired count and waiting. It also chooses the right instance type per workload based on pod resource requests.

# Karpenter NodePool example
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.k8s.aws/instance-category"
          operator: In
          values: ["c", "m", "r"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

EKS supports Kubernetes versions for 14 months after release. Clusters must be upgraded before end-of-support. The upgrade process is sequential - you cannot skip minor versions.

EKS add-ons are managed components that EKS can update automatically. Core add-ons include vpc-cni, kube-proxy, coredns, and aws-ebs-csi-driver.