Developers and platform teams both want Kubernetes self-service, but disagree on who owns it

Developers want Kubernetes environments when they need them, not a week later after a ticket queue. Platform teams answer for what those environments cost, who can reach them and whether they meet company policy. HPE product managers Marius Bogoevici and Karthik Subramanian described that tension to The New Stack.

Upstream Kubernetes provides orchestration and declarative APIs, but not a complete operating model. Subramanian says teams that build their own self-service layer hit two recurring problems. The first is tool and package sprawl: production-ready Kubernetes means curating an evolving set of CNCF projects for networking (CNI), storage (CSI), ingress, identity and policy.

Where self-built self-service breaks

The second is day-two lifecycle and hybrid complexity. Spinning up a cluster is easy; keeping it current across development, QA, staging and production is where work piles up, and HPE says every upgrade has to be checked against the components around it. Drift grows when clusters span bare metal, private clouds, edge sites and public clouds, and raw API access only moves that work rather than removing it.

A paved path, not unrestricted access

The answer is a paved path: approved Kubernetes services that developers request themselves, with access, configuration, placement, approvals and lifecycle controls defined by the platform team. The best candidates, Bogoevici says, are repeatable, low-risk and well-understood requests, so a developer gets a development cluster or a namespace without opening a ticket while the platform decides what a safe configuration looks like.

Developers then choose approved Kubernetes versions and cluster sizes, CPU, memory and storage quotas, and the lease duration of temporary environments. Network isolation, identity integration, security policy and cost allocation stay with the platform and are applied automatically. Production deployments travel the same approved path, with RBAC, audit and release controls owned by the platform and formal review for exceptions.

Speed has its own failure mode

In conventional IT, provisioning a dedicated environment for a new project runs through ticket handoffs between infrastructure, networking, security and storage teams, and often takes days to weeks. HPE says unifying orchestration, role-based access control and multi-tenancy into one operational experience compresses those workflows to minutes or hours. “When you reduce provisioning time from weeks to hours, that is super meaningful and tangible,” Bogoevici says.

Faster provisioning brings a risk of its own: teams lose track of what was provisioned and why. Visibility into utilization and cost, plus controls that retire temporary clusters, are the counterweight. Bogoevici calls ticket volume a poor measure of success and points to deployment success, exception rates and resource utilization. Security, he adds, belongs in the service design, so identity, RBAC, tenant isolation and policy arrive with the environment.