Right, let’s talk about EKS add-ons. This is where AWS tries to make your life easier by managing some of the core components of your Kubernetes cluster for you. Think of them as the official, blessed-by-AWS versions of things you’d otherwise have to go find, install, and update yourself. It’s a good idea, mostly. We’ll cover the big four: VPC CNI, CoreDNS, kube-proxy, and the EBS CSI Driver.

The first thing you need to know is that these aren’t magic. Under the hood, an EKS add-on is essentially AWS using its API to deploy a specific, validated version of a Helm chart or a manifest into your cluster’s kube-system namespace on your behalf. The value isn’t in the initial install—you could do that in five minutes. The value is in the ongoing management. AWS will tell you when new versions are available and handle the (mostly) safe rollout for you. It’s one less thing on your plate.

The VPC CNI: Your Network’s Nervous System

This is the big one. The VPC Container Network Interface (CNI) is the plugin that gives your pods their IP addresses. And here’s the critical bit you must internalize: it assigns IPs directly from your VPC’s CIDR block. Your pod isn’t hiding behind a NAT; it’s a first-class citizen in your AWS network. This is fantastic for performance and simplicity, but it has a massive, glaring implication: you can run out of IP addresses.

If you’ve given your worker node subnets a /24 (251 usable IPs), and you’re using an m5.4xlarge that can run 58 pods, then about four of those nodes can exhaust your entire subnet. It’s the most common “why are my pods stuck in Pending” issue. The fix? Bigger subnets (obviously), or enabling prefix delegation—a feature that lets the VPC CNI assign a /28 prefix per node instead of individual IPs, massively increasing your pod density.

You can check your current configuration and see how many IPs it thinks it has free. Let’s look at one of the VPC CNI pods:

# Get the logs from the VPC CNI daemonset to see its view of the world
kubectl logs -n kube-system -l k8s-app=aws-node --tail=20

You’ll see lines about “Number of interfaces attached to the node” and “maxIPsPerNode”. If maxIPsPerNode is eating up all your subnet IPs, you need to have a talk with your VPC design.

CoreDNS: The Cluster’s Phonebook

CoreDNS is your cluster’s DNS server. Every nslookup or service discovery call from your pods goes through it. EKS manages this as an add-on so you don’t have to worry about keeping up with patches for this critical piece of infrastructure.

The most common “issue” here is resource limits. By default, its memory limits are… optimistic. For a small cluster, it’s fine. But if you start having hundreds of services or thousands of pods, CoreDNS can get OOM-killed. You’ll know this is happening when DNS lookups start randomly failing. The fix is to adjust its resource requests and limits.

# This is a patch you might apply to give CoreDNS a bit more breathing room.
# Save this as `coredns-horizontal-autoscaler.yaml`
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: coredns-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Apply it with kubectl apply -f coredns-horizontal-autoscaler.yaml. This HPA will scale CoreDNS based on CPU, which is a decent proxy for its load. For large clusters, you might also want to increase the memory limit on the deployment itself.

kube-proxy: The Network Traffic Cop

kube-proxy is the component that makes Kubernetes services work. It’s the one that sets up the iptables (or ipvs) rules on each node to route traffic to the correct backend pods. The EKS add-on just ensures the right version is running and managed.

You generally don’t mess with this one. Its configuration is managed via a ConfigMap, and unless you have a very specific need to tune ipvs settings or sync periods, you can happily let AWS handle this. The main choice you had was between iptables and ipvs mode, but these days ipvs is the default and superior for most larger clusters due to better performance at scale. Consider this one a “set it and forget it” add-on.

The EBS CSI Driver: Because Pods Are Forgetful

Here’s the problem: you create a PersistentVolumeClaim, an EBS volume gets magically provisioned, and a pod uses it. Wonderful. Then you delete the pod. The EBS volume, being persistent, still exists. But what if you delete the PVC? By default, the corresponding PV gets deleted and… the underlying EBS volume gets deleted too. Gone. This is called the “Retain” policy, and it’s the default for dynamically provisioned volumes. It’s a data loss hazard waiting to happen.

The EBS CSI Driver add-on is what enables this dynamic provisioning. Before it was an add-on, you had to install it yourself. Now, AWS manages it. But you still have to be smart about your StorageClasses.

# A safer StorageClass configuration. Note the `reclaimPolicy`.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-retain-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true
parameters:
  type: gp3

The key is reclaimPolicy: Retain. This means when the PV is deleted, the EBS volume is orphaned but not deleted. You can then manually recover the data if it was deleted by mistake. You switch from a dangerous default to a safe, if slightly more administrative, one. Always, always change this for any production or staging cluster. The WaitForFirstConsumer binding mode is also crucial—it tells EKS to wait to provision the volume until a pod is scheduled, so it can provision the volume in the same Availability Zone as the pod. This avoids “no zone” provisioning errors.

So, should you use the add-ons? Absolutely. They remove operational toil. But as we’ve seen, using them doesn’t absolve you of understanding what they do. AWS manages the software lifecycle; you are still responsible for the configuration. Now you’re equipped to handle both.