Day 1 of a Kubernetes deployment typically feels like a milestone to an enterprise IT department: clusters are provisioned, networking is routed, and initial application containers are running. However, Day 2 exposes a far more complex reality: a cluster can be entirely healthy while the application running on top of it is failing. Once Kubernetes goes live in a production environment, organizations face a critical operational question: who owns what happens next?
In an interview with The New Stack, Karthik Subramanian, Principal Product Manager for HPE Morpheus Software at Hewlett Packard Enterprise (HPE), detailed how modern enterprise teams can successfully divide responsibility for post-launch Kubernetes operations. This division spans critical areas such as user access management, configuration drift mitigation, and routine cluster upgrades. As organizations scale their cloud-native infrastructure, establishing clear ownership boundaries between platform engineering teams and application development teams has shifted from a best practice to an absolute operational necessity.
The Evolution of Day 2 Kubernetes Challenges
To understand the complexity of Day 2 operations, one must look at the rapid evolution of container orchestration platforms over the past decade. Kubernetes has effectively become the operating system of the modern cloud, adopted by over 96% of Cloud Native Computing Foundation (CNCF) surveyed organizations for production workloads. However, while deployment tools have matured to make Day 1 provisioning fast and automated, the ongoing lifecycle management of these environments introduces significant friction.
Platform teams often focus on infrastructure stability, security compliance, and cost optimization, while application developers prioritize feature delivery, code velocity, and immediate resource availability. When a cluster experiences latency, a memory leak, or a failed certificate rotation, the lack of a predefined operational matrix frequently leads to finger-pointing between teams. This friction can result in extended downtime, diminished user trust, and severe security vulnerabilities. Subramanian’s insights, part of a broader four-part series exploring Kubernetes self-service and governance, provide a strategic framework for resolving these operational bottlenecks through structured functional ownership.
Dividing Platform and Application Team Responsibilities
At the core of sustainable post-launch governance is a definitive division between the teams building and maintaining the foundational platform and those consuming it to deliver business value. According to Subramanian, responsibilities cleanly break down into distinct functional domains, even in smaller organizations where a single engineer might wear multiple hats.
As teams scale, assigning a dedicated owner to each function eliminates ambiguity during high-pressure incidents. Platform teams traditionally retain ownership of infrastructure-level components, including cluster provisioning, node health, global security policies, underlying compute resources, and core networking fabrics. Conversely, application teams assume responsibility for the software artifacts running inside the clusters, including container image builds, application configuration maps, runtime performance tuning, business logic errors, and application-specific logging and monitoring.
Establishing Cloud-Level and Cluster-Level Standards
To maintain order across sprawling multi-cluster environments, platform teams must establish governance standards at two distinct layers: the broader cloud environment and the individual Kubernetes cluster.
At the cloud level, governance encompasses organization-wide policies. Platform teams establish identity and access management (IAM) frameworks, role-based access control (RBAC) permissions, centralized network policies, admission control requirements, and enterprise-wide backup and recovery objectives. Furthermore, this layer includes infrastructure-as-code (IaC) standards—frequently leveraging tools like Terraform or OpenTofu—alongside standardized service-level indicators (SLIs) and objectives (SLOs) for the entire underlying ecosystem.
At the cluster level, standardization shifts toward localized configurations tailored to the unique constraints of specific environments. This includes enforcing Kubernetes version support cadences, such as maintaining active support for a rolling window of two to three minor versions to prevent technical debt. It also involves standardizing naming conventions, resource labeling taxonomies, multi-tenancy namespace models, and cluster-specific network routing rules governing pod-to-pod communications.
Automating Governance and Upgrades with HPE Morpheus Software
To bridge the gap between rigid enterprise control and developer self-service, platforms like HPE Morpheus Software provide enterprise IT departments with a unified mechanism to orchestrate cloud resources, Kubernetes provisioning, service blueprints, workflows, and granular access controls.
Through the platform, IT administrators can configure service catalog access, resource quotas, budget thresholds, and automated approval policies, complete with native integrations into major IT service management (ITSM) systems. While developers gain the autonomy to request and spin up resources within predefined boundaries, the platform team retains ultimate authority over which requests require manual review and who possesses the authorization to alter production environments.
For Kubernetes clusters managed via HPE Morpheus Software, supported versions are delivered through standardized cluster layouts that explicitly define the software packages, container runtimes, and underlying dependencies required to provision a stable environment. Customers can seamlessly review available upgrades directly through the HPE Morpheus Software user interface or programmatic APIs, ensuring that all actions strictly adhere to the supported Kubernetes service and version matrix for their specific infrastructure.
Planning Rolling Upgrades to Limit Disruption
Upgrading production Kubernetes clusters is notoriously fraught with risk, as underlying API deprecations and control plane shifts can destabilize running workloads. To mitigate these risks, Subramanian outlines a rigorous, staged rolling upgrade process designed to minimize application downtime and user disruption.
The recommended upgrade methodology begins with comprehensive pre-check validation, verifying that all current workloads are compatible with the target Kubernetes version. Next, teams drain control plane nodes systematically, ensuring that API server availability remains uninterrupted during the transition. Worker nodes are then upgraded in a rolling fashion, allowing workloads to gracefully reschedule onto newly updated infrastructure without dropping active connections. Post-upgrade health validations verify that system pods, custom resource definitions (CRDs), and underlying storage drivers operate correctly before the process is marked complete.
Crucially, Subramanian emphasizes that an upgrade is not finished simply because the infrastructure nodes return to a "Ready" state in the terminal. True operational completion requires confirming that the application’s critical business paths function as expected, service-level objectives remain well within acceptable tolerances, and operations teams have clearly defined triggers for pausing or rolling back the deployment if anomalies arise.
Implementing a Task-by-Task Responsibility Matrix
To eliminate operational ambiguity across the entire lifecycle of a cloud-native application, modern IT organizations are increasingly turning to task-by-task responsibility matrices. By mapping every operational event—such as certificate rotations, security patch applications, namespace provisioning, and incident triage—to an accountable owner and a required approval gate, teams can streamline day-to-day coordination.
For instance, while a developer may trigger a deployment via a continuous integration pipeline, the platform team remains accountable for ensuring that the underlying container runtime security policies are enforced prior to image execution. Similarly, while application teams own the immediate triage of application-level bugs, platform engineers own the underlying infrastructure diagnostics required to determine if a node failure contributed to the software crash.
Testing Resilience and Measuring Operational Success
Adopting a robust governance framework is only effective if organizations proactively test their assumptions before a critical production failure occurs. Subramanian recommends that engineering teams conduct regular resilience drills and chaos engineering exercises within staging or lab environments.
These proactive tests should simulate real-world failure scenarios, such as sudden control plane outages, corrupted etcd database states, accidental RBAC permission revocations, and network partitioning between worker nodes. By observing how both the platform and application teams respond during these controlled simulations, organizations can identify communication gaps, refine runbooks, and streamline escalation pathways.
Furthermore, to accurately gauge whether post-launch operations are succeeding, organizations must move beyond vanity metrics like cluster uptime and track operational indicators that directly reflect system health and team efficiency. Key performance metrics recommended for enterprise Kubernetes environments include:
- Mean Time to Detection (MTTD) and Mean Time to Resolution (MTTR) for infrastructure and application anomalies.
- Frequency and success rate of automated cluster upgrades versus emergency hotfixes.
- Percentage of developer self-service requests successfully fulfilled without manual platform team intervention.
- Configuration drift frequency, tracking how often production clusters deviate from baseline infrastructure-as-code definitions.
- Resource efficiency ratios, comparing allocated CPU and memory quotas against actual utilization to prevent costly over-provisioning.
The Broader Impact and Future Implications
As enterprises continue to accelerate their cloud-native transformation journeys, the architectural challenges of Day 2 Kubernetes management will only intensify. The shift toward multi-cluster architectures, edge computing deployments, and complex AI/ML container workloads places unprecedented demands on enterprise platform engineering teams.
Without a clear division of labor, automated governance guardrails, and disciplined upgrade methodologies, organizations risk drowning in operational complexity. Clear owners, rigorously tested recovery procedures, and carefully configured automation platforms provide the essential foundation needed to operate Kubernetes at scale successfully. Ultimately, the true test of a mature enterprise deployment is not how quickly clusters can be spun up on Day 1, but whether teams can definitively identify who approves a configuration change, who responds when a pod fails, and what objective evidence proves that the business application is continuing to deliver value to its end users.
HPE will showcase its latest enterprise software solutions and governance frameworks at KubeCon + CloudNativeCon North America 2026, taking place in Salt Lake City from November 9 through 12, where platform engineering leaders can explore how HPE Morpheus Software continues to shape the future of governed Kubernetes self-service.
