Stop Managing EKS Add-ons by Hand

Originally published on graycloudarch.com . I was preparing to upgrade a production EKS cluster to version 1.32 when I discovered a problem. Four of our core cluster components—VPC CNI, CoreDNS, kube-proxy, and Metrics Server—were all running versions incompatible with EKS 1.32. I needed to update them before upgrading. And I had no easy way to do it. VPC CNI, CoreDNS, and kube-proxy had been installed automatically when the cluster was created, running in "self-managed" mode. Metrics Server was installed with kubectl apply -f metrics-server.yaml from some GitHub release page, months ago, by someone who is no longer on the team. No version pinning. No history of what changed or when. No way to test the upgrade before applying it to production. That's when I decided to stop managing EKS add-ons by hand. The Problem with Self-Managed Add-ons There are two categories of EKS add-ons, and most teams don't think about the distinction until they're stuck. Self-managed : You're responsible for