We recently sat down with one of the largest companies in the world. A Fortune 500 enterprise operating more than 10,000 Kubernetes nodes across hundreds of clusters. Their platform operations are vast, spread across geographies and business units, and deeply embedded in how they run their business.
They were not in the market for a new Kubernetes distribution. In fact, they were actively avoiding one. Their objective was to stay completely vendor-neutral by running pure upstream Kubernetes. No custom distributions, no opinionated tooling, no risk of subtle vendor lock-in. They had already made the right architectural choices for independence and portability. What they needed now was support that respected those decisions.
And support was proving hard to find.
Their internal infrastructure team was solid. But they were not career platform engineers. When things were humming, the team could manage just fine. But Kubernetes at this scale always throws curveballs. etcd behaving unpredictably. CoreDNS losing its mind. Kubelets crashing under pressure. These were not surface-level issues. They were deep platform problems that needed experience and insight to untangle.
What the company needed was an escalation path. Not a replacement platform.
Every vendor they spoke with offered the same response. “We can help, but only if you adopt our product. Move to our distro. Hand over management to our team.” In other words, change everything just to get help.
That was never going to fly.
What stood out to them was our Platform Engineer as a Service offering. We were not trying to sell a new control plane. We were offering what they actually needed. A Kubernetes-proficient team that could act as their Level 3 and Level 4 support. A partner to step in when their team hit a wall. Someone to help troubleshoot, guide upgrades, advise on best practices, and bring calm when things got chaotic.
We were not forcing a platform change. We were stepping into their world, not asking them to step into ours. Of course, if the platform itself turned out to be the source of a recurring issue, we would make recommendations. But that is very different from forcing them to adopt a vendor-curated stack.
We are not the maintainers of Kubernetes itself. If there is a core software defect, we help isolate it, reproduce it, and guide the process to escalate it upstream. But more often than not, these issues are operational. They stem from configuration, from scale-induced complexity, from the reality of running Kubernetes far beyond the "getting started" tutorials.
This is the kind of support that companies running upstream Kubernetes actually want. No lock-in. No bait-and-switch. Just real help, from people who know what they are doing.
So if you are running Kubernetes at scale, and every path to support seems to come with an agenda, take a step back.
- You do not need to trade your independence for a support contract.
- You do not need to replace what works just to feel safe.
- You just need access to a team who knows Kubernetes inside out.
Here at Portainer, we have built a vast depth of Kubernetes experience, both through the development of our own product and through our managed services team supporting some pretty serious customer environments. We make this experience available to our customers, either as a fractional service (staff augmentation) or we can manage your entire platform for you. You decide.
Speak to us here at Portainer to learn more.
COMMENTS