I have spent this week at ContainerDays in Hamburg, and one question has come up in almost every conversation with a platform lead; how do we help them manage the sprawl of Kubernetes environments they have inherited. The story is the same each time; discrete teams stood up their own environments over the last few years, the org has decided that a platform team now needs to own all of it, and the platform team is being asked to bring it under a single pane of glass.
The problem is, they are not actually asking for what they think they are.
What they want, when you push on the request, is to manage RedHat OpenShift, Rancher, VMware VCF, Mirantis Container Cloud, some EKS, some AKS, and usually a couple of other distros that landed as a proof of concept that never got turned off. What they think they need to buy is a Kubernetes multi-cluster/fleet manager, because all of these platforms claim to be a Kubernetes compliant distro (and they are, sort of…).
What they do not yet realize is that a fleet manager cannot help them, because the environments they have inherited are not just bare Kubernetes clusters; they are platforms, and the Kubernetes distro underneath is only one component of what the vendor sold, alongside its own operator, its own management console, its own identity model, its own storage integration, its own registry, and its own opinion about how upgrades happen.
You cannot just reach around all of that and manage the Kubernetes directly. Well, you can, but the moment you do, the vendor’s own management layer is completely blind to whatever you changed.
What the platform team actually needs is something quite different from a fleet manager. They need a management console federation tool; something that can provide a seamless synchronization of in-cluster user accounts, RBAC permissions, end to end visibility of application deployments, of cluster state/health/capacity, alerting and monitoring, centrally trigger and monitor Kubernetes cluster upgrades (including the requisite management console updates for the distro). This is required so that OpenShift OKE stays managed by OpenShift Platform, Rancher RKE/k3s stays managed by Rancher, VKS stays managed by VCF, EKS stays managed by AWS, etc.
Today, nothing like that exists. Every vendor in the market is either a fleet manager for a specific distro (Rancher for RKE, ACM for OpenShift, and so on), or a cross-distro Kubernetes manager that treats the underlying platforms as if they were just vanilla Kubernetes and quietly bypasses the vendor’s own control plane. There is no product that federates the management consoles themselves.
I need to be honest here because Portainer sits in the second camp for this specific problem. Portainer can absolutely manage multiple Kubernetes environments, including OKE, RKE, VKS, and the various cloud provider distros, and it does that well for teams whose primary constraint is a consistent operator experience across clusters. But if you already own OpenShift, and you already own Rancher, and you already own VCF, and each of those has a fully adopted management layer, then pointing Portainer directly at the underlying Kubernetes environment means fully handing over operational management to the Portainer layer, and ceasing use of the vendors own platform tooling.
The confusion at the root of all this is between discrete distros and discrete management tools. Most platform leads I speak with are treating them as the same problem; they think that if they can rationalize the distros, or at least manage them uniformly, the management tool problem will follow. It will not. The distro is the runtime; the management tool is the operational control plane; and it is entirely possible to have five distros with one management tool, or one distro with five management tools, and each combination has different consequences for governance, audit, upgrade paths, and how much institutional knowledge sits with which team.
Keeping every vendor’s native console alive alongside a federating layer above them is a defensible choice, and I understand why teams reach for it; it protects the investment and it keeps the compliance posture intact. But sometimes the smarter move is simplicity over complexity, and the cleanest way forward is to pick a single management tool, and then scale each of the underlying platforms down to nothing more than its specific distro. Let OpenShift be OKE, not the full OpenShift platform experience; let Rancher be RKE, not the Rancher management surface on top; let VCF be the VKS distro, not the whole VCF operator layer. Then one management tool sits above all of them, consistently, and the native consoles that used to be the source of truth are no longer trying to be.
That is a much bigger conversation than “buy a fleet manager”, and it is the conversation platform teams inheriting these estates need to be having with their executive sponsors before they sign anything.
If you are in that position now, and you want to talk it through with someone who has seen how these federations play out in practice (and where the traps sit that only surface at the second upgrade cycle), my team at Portainer are happy to help, no obligation, all that is needed is a call.