Kubernetes Modernization: Rebuilding Ageing Clusters on EKS, AKS, GKE
Kubernetes modernization rebuilds or upgrades an existing container platform, whether self-managed clusters, outdated versions or hand-configured managed clusters, into a current, managed, GitOps-driven platform. NTSPL moves workloads to EKS, AKS or GKE, catches up skipped versions and removed APIs, replaces retired components such as ingress-nginx, and sets multi-tenant guardrails for platform and product teams.
Delivered on
In scope
Why ageing clusters become an upgrade trap
Many Indian teams adopted Kubernetes between 2018 and 2022 with kubeadm, kops, Rancher RKE1 or OpenShift 3, and the clusters have aged faster than the applications. Typical findings: control planes several minor versions out of support, Helm charts using removed APIs, ingress-nginx as the only edge, etcd backups never restored, and node images patched by hand. Managed clusters are not immune: click-built clusters with no IaC, one shared namespace for everyone, and extended-support charges because nobody owned upgrades. Every version jump becomes a quarter-long project.
NTSPL rebuilds rather than patches when clusters are more than two minor versions behind. New managed clusters are defined in Terraform, platform add-ons arrive through GitOps, and workloads move namespace by namespace with blue-green cluster cutover. We scan manifests with Pluto and kubent, migrate the edge to Gateway API, replace static node groups with Karpenter, AKS node auto-provisioning or GKE Autopilot, and give each team a namespace with quotas, network policies and admission rules. Afterwards, upgrades are a routine twice a year.
Signals your Kubernetes platform needs rebuilding
Signals you need Kubernetes Modernization
- Clusters run a Kubernetes minor version out of standard support, or you pay EKS extended-support or AKS LTS charges without an upgrade plan.
- Control planes are self-managed (kubeadm, kops, Rancher RKE1, OpenShift 3.x) and etcd backups have not been restored in six months.
- ingress-nginx is the only ingress controller, although Kubernetes SIG Network retired the project in March 2026.
- Changes are applied with kubectl from laptops and nobody can recreate a cluster from code in under a day.
- More than ten teams share clusters without namespace quotas, network policies or admission controls.
When to choose something else
- Fewer than ten stateless services on Kubernetes: moving them to Cloud Run, Container Apps or ECS on Fargate may cost less than modernizing the cluster.
- You want someone to operate an already-current cluster, covering patching, upgrades and incidents: that is Managed Kubernetes & Containers under Managed Cloud Services.
- The concern is cost per namespace or idle resource requests: Kubernetes FinOps handles allocation and rightsizing without a rebuild.
Platform modernization workstreams
Version and API audit
Pluto and kubent scans of manifests and Helm releases, add-on compatibility matrix and a version path to current.
Cluster rebuild as code
Terraform or OpenTofu modules for clusters, node pools, networking and identity, changed only through pull requests.
Edge and traffic
Migration from ingress-nginx to a Gateway API implementation, with TLS automation and WAF integration.
GitOps delivery
Argo CD or Flux with app-of-apps structure, environment overlays and drift alerts.
Node autoscaling and images
Karpenter, AKS node auto-provisioning or GKE Autopilot, with automated node image updates.
Multi-tenancy guardrails
Team namespaces with ResourceQuotas, NetworkPolicies, Pod Security Admission and Kyverno or Gatekeeper policies.
GitOps-managed multi-tenant cluster design
GitOps-Driven Multi-Tenant Kubernetes Platform
Terraform creates managed clusters with their identity and network wiring, then Argo CD reconciles platform add-ons and team workloads from Git. A Gateway API edge, admission policies and autoscaled node pools give each team an isolated, upgradeable slice of the platform.
Select any component
GitOps-Driven Multi-Tenant Kubernetes Platform: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
EKS, AKS and GKE modernization paths
EKS Auto Mode suits teams that want AWS to manage nodes and core add-ons; otherwise we run Karpenter. Cluster insights flags deprecated API use before each upgrade, ahead of extended-support charges.
AKS Automatic gives production defaults for new clusters, Application Gateway for Containers provides a managed Gateway API edge, and Fleet Manager stages upgrades across dev, UAT and production.
Autopilot removes node management for most tenants; release channels with maintenance windows and exclusions make upgrades routine, and the GKE Gateway controller implements Gateway API natively.
Platform choices that set your future upgrade cost
Rebuild or upgrade in place
Upgrade in place if the cluster is at most two minor versions behind, already managed and defined as code. Rebuild with a blue-green cutover when it is three or more versions behind, self-managed or click-built. Managed services upgrade the control plane one minor version at a time, so a long sequential catch-up usually takes longer than a clean rebuild.
Cluster topology
Default to one cluster per environment per region, shared by teams through namespaces, until a team has a distinct compliance scope such as PCI DSS, or noisy workloads such as GPU jobs. Avoid per-team clusters below about 30 nodes each, because upgrade, add-on and observability overhead multiplies with every cluster you add.
Moving from Ingress to Gateway API
Map every Ingress annotation in use, including rewrites, auth, rate limits and canary rules, to Gateway API resources or implementation policies before cutover. Annotations with no equivalent, such as custom configuration snippets, must be redesigned. Run old and new edges in parallel behind weighted DNS, shifting 10%, then 50%, then 100% over a week.
Upgrade cadence
Commit to two upgrades a year, staying one minor version behind the newest available. Upgrade dev first, UAT a week later and production after two weeks of soak, using release channels or Fleet Manager. Put PodDisruptionBudgets on every production deployment so node drains during upgrades never take a service below its minimum replicas.
Blue-green cluster migration plan
Platform audit
Inventory versions, removed APIs, add-ons, tenancy and external dependencies of every cluster.
New cluster build as code
Terraform clusters, identity, networking, GitOps bootstrap and policies in audit mode.
Manifest remediation and Gateway API
Fix removed APIs, upgrade Helm charts and run the new edge in parallel.
Namespace-by-namespace migration
Move workloads with weighted DNS, stateful workloads last.
Old cluster retirement and upgrade drill
Decommission the old platform and run the first in-place minor upgrade as a drill.
What you receive
Platform health targets after modernization
| KPI | Typical target |
|---|---|
| Clusters within one minor version of the provider default | 100% |
| Time to recreate a full cluster from code | Under 2 hours |
| Tenant onboarding time | Under 1 day |
| Production downtime during minor upgrades | Zero |
| Manual kubectl changes in production | Zero, with drift alerts inside 5 minutes |
What breaks during Kubernetes rebuilds
| Risk | How NTSPL prevents it |
|---|---|
| Hidden dependence on removed APIs or annotations | Automated scans plus a dry-run deployment of every Helm release against the target version before cutover. |
| Stateful workloads losing data in migration | Stateful sets move last, via volume snapshots or application-level replication, with restores tested in the new cluster first. |
| Policy rollout breaking teams | Admission policies run in audit mode for two weeks with a violation report per team before enforcement. |
| IP exhaustion in new clusters | Subnet and pod CIDR ranges are sized for three times current pod counts, using prefix delegation or overlay networking where supported. |
EKS, AKS or GKE for a modernized Kubernetes platform?
Pick the managed Kubernetes service on the cloud where your data and identity already live; switching clouds for Kubernetes alone rarely pays back. On features, GKE Autopilot offers the most hands-off node operations and mature release channels. AKS Automatic and Fleet Manager suit Microsoft-centric enterprises that run on Entra ID. EKS with Karpenter or Auto Mode gives the widest instance choice and strong Spot economics. All three now support Gateway API and workload identity. For multi-cloud estates, standardise the GitOps tool, policy engine and telemetry agents across clusters rather than trying to standardise on one provider.
Key facts: Kubernetes Modernization
Kubernetes Modernization in Practice
2 Kubernetes Modernization scenarios, from OTT streaming (regional-language) and Telecom tower infrastructure, plus related platform case studies.
Regional OTT service moves an out-of-support kubeadm cluster to GKE with zero downtime
Tower company rebuilds end-of-life Rancher clusters on AKS and removes shared admin access
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Health TPA meets 1-hour cashless pre-auth target with AKS and KEDA-scaled adjudication
Kubernetes Modernization: Frequently Asked Questions
What does a Kubernetes platform modernization cost?
For one environment set (dev, UAT and production) with 40-120 workloads, expect 10-12 weeks and roughly INR 35-70 lakh in services, depending on how many charts use removed APIs and how much stateful data moves. Running old and new clusters in parallel adds 4-6 weeks of overlap cost, which we budget explicitly.
What should we do about the ingress-nginx retirement?
Plan a Gateway API migration now. Kubernetes SIG Network retired the ingress-nginx project in March 2026, so it no longer receives releases or security fixes. We inventory annotations, choose a Gateway API implementation native to your cloud or an open-source one, and shift traffic gradually using parallel edges.
Can we jump from a very old Kubernetes version without downtime?
Yes, usually through a new cluster rather than sequential in-place upgrades. We build the target cluster at a current version, fix manifests for removed APIs, then move namespaces with weighted DNS. Users see no downtime; stateful workloads get a short planned window only where replication is not possible.
How do we meet CERT-In and RBI expectations on Kubernetes?
Send control-plane audit logs and node logs to central storage retained for 180 days in India, run regulated workloads in Indian regions such as AWS Mumbai, Azure Central India or Google Cloud Mumbai, and restrict API servers to private endpoints. Admission policy reports give auditors evidence that controls are enforced, not just documented.
Should we move from OpenShift to EKS, AKS or GKE?
Only if OpenShift's integrated features are lightly used and its subscription is a major cost. Teams relying on Routes, BuildConfigs and the developer console face rework. We compare the subscription against managed-service cost plus the effort to replace those features before recommending any move.
Who runs the platform after modernization?
Your platform team or a managed service. We hand over the Terraform, GitOps repositories and runbooks, and run the first upgrade with your team as a drill. Day-to-day patching and incident response can then move to NTSPL's managed Kubernetes service if you prefer not to staff it.