Kubernetes
Who owns Kubernetes after launch? Breaking down the Day 2 operations gap
A healthy cluster doesn't guarantee a healthy application—clarifying ownership between platform and application teams is crucial for post-deployment success.
The New Stack
Getting a Kubernetes cluster live feels like a victory for many IT departments: infrastructure is standing, networking routes traffic, and containers run. But the real complexity emerges in the weeks and months after—what's known as Day 2 operations. A cluster can report healthy status while applications falter, raising an uncomfortable question: when problems emerge, who's responsible for fixing them?
The ownership challenge after launch#
This gap between infrastructure health and application performance leaves teams scrambling to assign responsibility. According to Karthik Subramanian, Principal Product Manager for HPE Morpheus Software, the issue stems from unclear handoffs between the groups building and consuming the platform. Without deliberate governance design, operational work falls through the cracks—someone fixes the cluster while someone else tracks the application, but nobody connects the two.
Mapping team responsibilities#
Success requires dividing labor intentionally between two complementary groups:
-
Platform teams: Cloud architects, Kubernetes administrators, security specialists, and monitoring engineers who maintain the overall environment. They handle cluster provisioning, namespace allocation, version management, storage and networking plugin administration, security policy enforcement, and infrastructure drift detection.
-
Application teams: Developers, QA engineers, and deployment specialists who operate within designated boundaries. They manage application releases, deploy workloads to their allocated namespaces, and leverage cluster capabilities without touching the control plane.
Subramanian emphasizes that these are functional roles rather than individual job titles—a single person might perform multiple functions on smaller teams, but growth and scale benefit from explicit ownership assignments that clarify handoffs and access decisions.
Setting standards at two levels#
Platform teams can establish governance at distinct scopes. Cloud-level policies span the entire environment: access and role-based controls, network rules, admission policies, backup recovery targets, infrastructure-as-code patterns like Terraform, and service-level benchmarks for monitoring.
