Overview
EKS runs the control plane, but node groups, add-ons, certificates, backups and every upgrade deadline stay with the customer. A small platform team ends up planning around AWS support dates in between product work. Under Tier 3 managed services, AceMQ operates the clusters inside the customer's own AWS accounts.
Challenge
The platform team runs several production clusters and has no time to own the version calendar. Minor upgrades are postponed until AWS extended support is the only option, node groups lag the control plane, add-on versions drift, and nobody has restored a Velero backup since it was configured. Certificates are renewed by whoever notices an expiry date first.
Environment
Production and staging EKS clusters in two AWS accounts, managed node groups across three availability zones, the VPC CNI, CoreDNS and kube-proxy add-ons, ingress and cert-manager, Prometheus alerting, and a GitOps repository for delivery.
Approach
AceMQ starts with an assessment of version position against the EKS support calendar, removed APIs, add-on and operator compatibility, backup and restore history, certificate expiry and monitoring gaps. It remediates the active risks, agrees access and a change process in the customer's accounts, then takes the pager. Cluster platform work is delivered by AceMQ with partner Kubernetes specialists under one contract.
Solution
- Assessed each cluster's version against the EKS standard and extended support dates and wrote a minor-by-minor upgrade plan
- Scanned manifests, Helm releases and live objects for APIs removed by each target release and added the check to CI
- Brought node groups and add-ons in line with the control plane, replacing nodes group by group with pauses sized to measured recovery time
- Deployed Velero with retention set against the customer's recovery objectives and scheduled restore tests into a scratch cluster
- Inventoried every certificate that can take a cluster down and put expiry alerts and rotation runbooks in place
- Took over monitoring and on-call, with the 15-minute Sev 1 response and a written root-cause analysis after each P1
Outcome
The customer receives a version calendar and upgrade plan for every cluster, a tested restore procedure, certificate and add-on inventories, current runbooks and a handover pack. Upgrades, patching and the pager move to AceMQ, and the platform team returns to product work. Clusters, data and the AWS bill stay in the customer's accounts.