kube-proxy is self-managed and never upgraded on EKS workloads

Summary

On EKS workload clusters, kube-proxy is a self-managed add-on that PTD never upgrades. It stays pinned at the cluster's creation version while the control plane and nodes advance. This creates a version mismatch — kube-proxy runs at a different (older) Kubernetes version than the control plane and kubelets — which EKS flags as version skew in upgrade insights and which eventually blocks upgrades. We should adopt kube-proxy as an EKS managed add-on, pinned via config.

Observed

• Control plane / kubelets: 1.35 — kube-proxy: v1.33.0-eksbuild.2 (two minors behind, frozen at cluster creation, Aug 2025)
• aws eks list-addons does not include kube-proxy, confirming it's self-managed
• EKS upgrade insights flagged kube-proxy version skew

How it happens

1. At CreateCluster, EKS bootstraps kube-proxy as a self-managed workload in kube-system. Self-managed add-ons are installed once and never updated by EKS.
2. Our builder sets DefaultAddonsToRemoves = ["vpc-cni"] (lib/aws/eks_cluster.go:304) but leaves kube-proxy as EKS's self-managed default.
3. PTD never adopts or bumps it (absent from the codebase and git history).
4. Across control-plane upgrades, everything advances except kube-proxy — owned by neither EKS nor PTD.

AWS docs

• Amazon EKS add-ons — self-managed add-ons require manual updates; AWS recommends the managed type.
• Update the kube-proxy self-managed add-on
• Cluster insights — kube-proxy version skew check.

Recommendation

Adopt kube-proxy as an EKS managed add-on, pinned via config — the pattern already used for aws-ebs-csi-driver (EKSEbsCsiAddonVersion, lib/types/workload.go:99). An in-place kubectl bump is not preferred: it fixes the symptom but leaves the component unowned, so it drifts again on the next upgrade.

Migration plan

1. Add kube-proxy managed add-on to the EKS builder (lib/aws/eks_cluster.go).
2. Add a kube_proxy_addon_version field to AWSWorkloadClusterSpec with a version-appropriate default (follow the EbsCsiAddonVersion pattern).
3. Adopt with OVERWRITE conflict resolution (the self-managed workload already exists); adopt at a version within skew of the control plane.
4. Test on a staging cluster — adoption reconciles the running DaemonSet; confirm no Service-routing disruption.

Acceptance criteria

• kube-proxy is an EKS managed add-on on PTD-provisioned EKS clusters
• Version is declarable in ptd.yaml with a sensible default
• Self-managed → managed adoption handled non-disruptively (OVERWRITE)
• kube-proxy skew insight clears on a migrated cluster

Start with lib/aws/eks_cluster.go:304 and the EbsCsiAddonVersion pattern in lib/types/workload.go:99. Add the kube-proxy managed add-on and its ptd.yaml-configurable version, using OVERWRITE for adoption. Validate on a staging EKS cluster that the DaemonSet is adopted without service-routing disruption and that the version-skew insight clears.