AWS EKS
Upgrades and Maintenance
EKS Addon
Amazon EKS add-ons let you install and manage essential cluster services—such as the VPC CNI, kube-proxy, and CoreDNS—through the AWS API. While these components are automatically provisioned with your EKS cluster, turning them into managed add-ons enables AWS to handle version alignment and automated upgrades. However, this convenience can introduce limitations and additional steps during control plane or worker node upgrades.
What Are EKS Add-ons?
EKS add-ons are extensions that AWS maintains for compatibility with your cluster’s Kubernetes version. They include:
- Amazon VPC CNI: Integrates Kubernetes pod networking directly with your VPC.
- CoreDNS: Provides DNS resolution for in-cluster services.
- kube-proxy: Manages cluster networking rules.
By default, the VPC CNI ships as a managed add-on, while CoreDNS and kube-proxy run as unmanaged core components. Converting these into managed add-ons synchronizes their lifecycle with your cluster.
Inspecting Default Add-ons in the Console
Let’s explore an EKS cluster via the AWS Management Console. Here’s my cluster named kodekloud, running Kubernetes v1.29. The Amazon VPC CNI appears automatically under the Add-ons section.
Even though only the VPC CNI shows up as an add-on, you can verify that CoreDNS and kube-proxy are running:
kubectl get pods -A
Converting CoreDNS and kube-proxy to Managed Add-ons
To bring CoreDNS and kube-proxy under managed add-on control:
- In the AWS Console, go to Add-ons for your cluster.
- Select CoreDNS and kube-proxy.
- Click Install; the console auto-selects a compatible version via the EKS API.
Next, review the default settings (IAM role, version) and confirm the installation:
Note
During installation, you may observe both unmanaged and managed instances of these components running in parallel. This is normal until you remove the original unmanaged deployments.
Viewing Add-on Status
Once installed, all add-ons appear as Active in the console—despite already running under the hood.
You can update each add-on individually when AWS releases a newer compatible package. The console highlights available updates even if your cluster’s components are up-to-date with Kubernetes standards.
kubectl get pods -A
When you click Update, EKS triggers an internal API call to patch the add-on manifest. You don’t control the rollout strategy, and the console does not expose the underlying YAML changes.
Officially Supported vs. Marketplace Add-ons
AWS maintains a growing roster of officially supported add-ons:
Add-on | Use Case | Example Installation |
---|---|---|
AWS Distro for OpenTelemetry (ADOT) | Collect and export metrics/traces | eksctl create addon --name aws-otel-collector |
CSI Snapshot Controller | Volume snapshot management | eksctl create addon --name aws-ebs-csi-node |
EKS Pod Identity Agent | Enable IAM roles for Kubernetes service accounts | eksctl create addon --name aws-iam-authenticator |
Marketplace add-ons introduce extra dependencies and may lag behind Kubernetes releases. For instance, attempting to install KubeCost without a subscription—or if no compatible package exists—can block your upgrade path:
Warning
Marketplace add-ons may show “no versions available” if they don’t support your Kubernetes version. This can delay critical upgrades.
Best Practices: Own Your Add-on Manifests
For maximum control over versions, rollout timing, and configuration, consider managing cluster services yourself:
- Use Helm charts or plain YAML manifests.
- Incorporate add-on deployments in your GitOps pipeline.
- Align CoreDNS and kube-proxy versions directly with your control plane and node versions.
This approach streamlines testing and upgrades, removing external bottlenecks.
Conclusion
While EKS add-ons simplify cluster service management, they can complicate upgrades and reduce your visibility into rollout processes. Evaluate your operational requirements to decide which components you want AWS to manage and which you prefer to control directly.
References
Watch Video
Watch video content