India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Managed Kubernetes Operations: Upgrades, Node Patching, Cluster SLAs
Managed Kubernetes operations is the day-2 running of production clusters after they are built: keeping control planes and nodes on supported versions, patching node images, maintaining add-ons such as ingress and autoscalers, and responding to cluster incidents. NTSPL operates EKS, AKS and GKE clusters this way, with quarterly upgrade cycles and 24x7 SLAs, so platform teams can focus on developer experience.
Delivered on
In scope
Running Production Kubernetes After Day One
Kubernetes ships about three minor versions a year, and each managed service retires old ones on a fixed schedule. Teams that built a cluster in a hurry often end up two or three versions behind, facing extended support fees on EKS or forced upgrades on GKE and AKS. Meanwhile ingress controllers, cert-manager, CSI drivers and service meshes each have their own release cycles and compatibility rules. The first upgrade attempt usually breaks something: a removed API version in a Helm chart, a PodDisruptionBudget that blocks node drains, or a webhook that times out.
NTSPL runs clusters on a predictable cadence. Every quarter we scan manifests and live objects for deprecated APIs, upgrade non-production first, soak for a week, then upgrade production node pool by node pool with surge capacity. Node images are refreshed at least monthly. Add-ons follow a compatibility matrix we maintain per cluster. Incidents such as pending pods, node pressure or failed rollouts get the same 24x7 response as any other production alert.
Cluster Warning Signs That Need an Operations Owner
Signals you need Managed Kubernetes & Containers
- Any production cluster is two or more minor versions behind the latest available on your provider
- EKS extended support charges have appeared on your bill, or a GKE or AKS forced upgrade notice has arrived
- Node images have not been refreshed in over 60 days
- The last cluster upgrade caused an outage, and nobody wants to do the next one
- Your platform team of one or two people spends more time on upgrades than on developer tooling
When to choose something else
- You are still containerising applications or designing the cluster platform; that is a build engagement, and operations starts once clusters carry production traffic
- You mainly want lower Kubernetes spend through namespace allocation and requests tuning; that is Kubernetes FinOps, which we can run alongside
Cluster Lifecycle and Incident Duties We Carry
Version upgrades
Quarterly control plane and node pool upgrades, non-production first, with deprecated API scans and rollback plans.
Node image patching
Monthly node image refresh, and within 72 hours for exploited kernel or runtime vulnerabilities, using surge upgrades.
Add-on lifecycle
Ingress controllers, cert-manager, external-dns, CSI drivers, autoscalers and observability agents kept within a tested compatibility matrix.
Cluster incident response
24x7 handling of pending pods, node NotReady, DNS failures, certificate expiry and failed rollouts at the cluster layer.
Cluster backup and policy
Scheduled backups of cluster state and persistent volumes, plus admission policies for security baselines.
Quarterly Upgrade Train with Deprecation Gates
Quarterly Kubernetes Upgrade Train with Deprecation and Drain Gates
Each cycle starts with deprecated API and add-on compatibility scans, upgrades non-production clusters and soaks them, then moves production node pools with surge capacity. Node image refreshes and incident response run continuously between cycles.
Select any component
Quarterly Kubernetes Upgrade Train with Deprecation and Drain Gates: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Operating EKS, AKS and GKE Day to Day
EKS upgrade insights flag deprecated API usage before a control plane upgrade, and we use EKS managed add-ons where available so versions follow the cluster.
We set the node OS upgrade channel to NodeImage with a planned maintenance window, and use Fleet Manager update runs to stage upgrades across several clusters.
We enrol clusters in the Regular or Stable release channel and use maintenance exclusions to keep upgrades away from business peaks without falling off support.
Upgrade Cadence, Node Strategy and Add-on Ownership
Upgrade cadence
Upgrade every quarter, keeping production no more than one minor version behind the latest your provider offers. Skipping versions is not possible for control planes, so two quarters of delay means two back-to-back upgrades. On EKS, plan to finish before the 14-month standard support ends; on GKE, use release channels with maintenance exclusions rather than opting out.
Managed nodes or self-managed
Use managed node groups, EKS Auto Mode, AKS node pools or GKE Autopilot unless you need custom kernels or GPUs with special drivers. Managed nodes make image refresh a single operation. Karpenter on EKS suits fleets with varied instance needs and Spot usage; fixed node groups suit steady, predictable workloads and simpler debugging.
Who owns add-ons
The platform operator should own cluster-wide add-ons such as ingress, cert-manager, CSI, autoscalers and policy engines, because they gate upgrades. Application teams own their Helm charts and namespace resources. Write this split into the RACI and keep add-ons in a GitOps repository with Argo CD or Flux so versions are visible and changes reviewable.
Blue-green clusters or in-place
Upgrade in place with surge nodes for most clusters; it is cheaper and well supported. Use blue-green cluster replacement when jumping several versions, changing CNI, or when the cluster carries years of manual drift. Blue-green needs stateless workloads or externalised state and DNS or load balancer cutover, and doubles cost during the switch.
Onboarding Clusters into Managed Operations
Cluster health review
Inventory versions, add-ons, node images, PDBs, access and backups; scan for deprecated APIs.
Catch-up plan
Plan upgrades to reach a supported version, with app owner tickets for API changes.
GitOps for add-ons
Move add-ons into a GitOps repository with pinned versions and the compatibility matrix.
First upgrade train
Upgrade non-production, soak, then production pools; hand over to the quarterly cadence.
What you receive
Cluster Operations Service Levels
| KPI | Typical target |
|---|---|
| Production clusters within one minor version of latest | 100% |
| Node image age | Under 35 days |
| Upgrade-caused production incidents | Zero P1 |
| Cluster-layer P1 response | Acknowledged in 5 minutes, engineer engaged in 15 |
Kubernetes Operations Failure Modes
| Risk | How NTSPL prevents it |
|---|---|
| Removed API versions in Helm charts break deployments after upgrade | Deprecation scans four weeks ahead and blocking tickets to app owners before production upgrades. |
| Node drains stall on strict PDBs or single replicas | Pre-upgrade PDB check and agreement with app owners to run at least two replicas for production services. |
| Admission webhooks fail during upgrade and block all pod creation | Webhook failure policies and timeouts reviewed, and webhook services given high-priority scheduling. |
Managed Kubernetes service vs managed Kubernetes operations: is EKS, AKS or GKE not enough?
The provider manages the control plane: API server availability, etcd and the Kubernetes binaries. You still own choosing when to upgrade, checking your manifests for removed APIs, upgrading nodes, maintaining add-ons, setting PDBs and responding when pods will not schedule. GKE Autopilot and EKS Auto Mode take on more of the node layer, but upgrades and add-ons remain your problem. Managed operations fills that gap with a team that runs upgrades every quarter across many clusters, so the process is routine rather than a yearly crisis.
Key facts: Managed Kubernetes & Containers
Managed Kubernetes & Containers in Practice
2 Managed Kubernetes & Containers scenarios, from B2B SaaS CRM and Card-processing fintech, plus related platform case studies.
B2B CRM SaaS catches up three GKE versions without a customer-visible outage
Card-processing fintech keeps EKS and AKS node images inside a 30-day PCI patch window
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
Managed Kubernetes & Containers: Frequently Asked Questions
How is managed Kubernetes operations priced?
We price per cluster by size and criticality. A production cluster with up to about 50 nodes typically costs ₹1-2.5 lakh a month including quarterly upgrades, monthly node refresh, add-on lifecycle and 24x7 cluster incident response. Non-production clusters are priced lower.
What happens if our clusters are several versions behind?
We plan sequential upgrades, one minor version at a time, typically two to three weeks apart after deprecated APIs are fixed. Where the gap is large or the cluster is heavily drifted, a blue-green rebuild on the current version can be faster and safer.
Do you also support our application deployments?
We support the cluster layer and deployment tooling such as Argo CD or Flux. Application rollouts, Helm values and code-level failures stay with your teams, though we diagnose whether a problem sits in the cluster or the application during incidents.
How do you meet PCI DSS or RBI requirements on clusters?
We keep node images patched within the timelines your compliance programme sets, such as one month for critical patches under PCI DSS, enforce admission policies, and keep clusters for regulated payment data in Indian regions in line with RBI's data storage directive. Evidence is included in monthly reports.
Can you operate clusters on more than one cloud?
Yes. Many clients run EKS and AKS or GKE together. We keep one version register and add-on matrix across all clusters and align upgrade trains, while respecting each provider's maintenance and release mechanisms. Upgrade trains are aligned so clusters stay on the same minor version.
Do you handle ECS, Cloud Run or Azure Container Apps?
Yes, at a lighter level and lower price. Amazon ECS, Cloud Run and Azure Container Apps have no node or Kubernetes version upgrades for you to run, so we focus on task and revision health, scaling settings, base image patching, secrets rotation and 24x7 incident response for the services.