The business case says the new platform will improve developer velocity and reduce operational overhead. Both can be true. Neither happens by itself, and the mechanism by which they happen is a team that did not exist before.
The work that appears
Cluster lifecycle and upgrades, several times a year, forever. Operator inventory and maintenance. Storage class design and the relationship with the storage team. Network policy. Identity integration. Monitoring and alerting for the platform as distinct from the applications. Capacity management. Cost attribution. A base image and its patch cadence. Documentation. Answering questions.
None of this is application work, so application teams do not do it. Most of it is not traditional infrastructure work, so the infrastructure team does not recognise it. It accumulates in the gap.
The symptoms
The cluster is two versions behind because upgrading is nobody’s scheduled work.
Every team invented their own deployment manifests, and there are six ways to do the same thing.
There is one person who understands the cluster, and the organisation’s real availability risk is their annual leave.
Nobody can say what anything costs.
A security question about the platform takes a week to answer because nobody owns the answer.
These read as technical problems. They are a staffing problem that expresses itself technically.
What the role actually is
Not a Kubernetes administrator. A team that treats the platform as a product with internal customers: it has a roadmap, a support model, documentation, and a defined interface that application teams build against.
The distinction matters because it changes what good looks like. An administrator keeps the cluster up. A platform team makes it possible for twenty application teams to ship without each of them learning Kubernetes.
The minimum viable version
For an enterprise running one or two production clusters: two people who between them own the platform, with a named backup, and explicit time allocated rather than “when they can fit it in”.
Two, not one. One person is a single point of failure who cannot take leave, cannot be ill, and cannot leave without taking the platform’s operating knowledge with them. I have watched that situation resolve badly more than once.
Their skills should span both worlds. Someone who knows Kubernetes and nothing about storage or networking will build something that fails in ways they cannot diagnose. Someone from infrastructure who has learned Kubernetes is frequently the better hire, because the operational instincts are the harder part to teach.
How to fund it
Put it in the business case as a line item, at the start, with names if possible. A business case that shows a platform cost with no operating cost is not a business case, it is a purchase request.
The number is not large compared to the infrastructure. It is large compared to zero, which is what is usually budgeted.
The uncomfortable truth
Most Kubernetes disappointments I have seen were not technology failures. The technology did what it says. The organisation adopted a platform that requires continuous specialist attention and did not allocate any, then concluded the platform was the problem.
If you cannot staff it, that is a legitimate input to the decision. There are simpler platforms, and running a simple thing well beats running a sophisticated thing badly. Deciding that honestly at the start is a better outcome than discovering it in year two.