One Control Plane for Kubernetes on AWS, GCP, Azure, Scaleway and On-Prem: 8 Options Compared (2026)

There is no single tool that provisions your clusters, enforces your policies and runs your CI/CD on AWS, GCP, Azure, Scaleway and on-prem. Anyone telling you otherwise is selling you one layer and quietly leaving you the other two. The eight credible options split into three categories: cluster fleet managers (Spectro Cloud Palette, Rancher, Platform9), declarative infrastructure control planes (Crossplane, Spacelift), and application delivery platforms (Qovery, Devtron, Northflank). Which shortlist you take depends on whether your bottleneck is cluster operations or developer delivery.

Most teams that consolidate well run two tools, not one. I will show you why, where each tool actually fits, and how to get identical policies and pipelines on every cluster regardless of where it runs.

Key points

• No single tool covers all three layers of multi-cloud Kubernetes. The layers are cluster lifecycle (provision, upgrade, scale clusters), policy and governance (who can do what, what is allowed to run), and application delivery (CI/CD, environments, developer self-service). The teams that get this right run two tools, not one.
• For cluster fleet lifecycle across clouds, bare metal and edge: Spectro Cloud Palette, Rancher (SUSE), Platform9 and Crossplane are the credible options. For one deployment and environment workflow across clouds: Qovery, Devtron and Northflank. Spacelift sits in the IaC-orchestration lane and does neither on its own.
• Identical policy across clouds comes from Kubernetes-native admission control (Kyverno or OPA/Gatekeeper) applied by GitOps (Argo CD or Flux), not from your provisioning tool. The rules then travel with the workload whether it lands on EKS, GKE, AKS, Scaleway Kapsule or an on-prem cluster.
• Qovery gives one control plane for deployments, environments and RBAC across AWS, GCP, Azure, Scaleway and your own existing Kubernetes cluster, with clusters running in your own accounts (BYOC) so committed-use discounts, Savings Plans and data residency stay yours. It is not a bare-metal or edge fleet manager.
• Consolidation saves money through fewer bespoke per-cloud pipelines and fewer idle non-production clusters, not through the license. Per-cluster control-plane fees (roughly $0.10/hour, about $73/month per cluster on EKS, AKS Standard and GKE) multiply with every cloud you add, and non-production clusters are where most Kubernetes waste sits.

What are the options for managing Kubernetes clusters across AWS, GCP, Azure and on-prem from one place?

There are eight credible options and they fall into three categories: cluster fleet managers (Spectro Cloud Palette, Rancher by SUSE, Platform9), declarative infrastructure control planes (Crossplane, Spacelift), and application delivery platforms (Qovery, Devtron, Northflank). Start from your bottleneck: if it is cluster operations, look at the first two categories; if it is developers waiting on deployments and environments, look at the third.

The three layers, one line each:

• Cluster lifecycle - provision, upgrade, scale and retire clusters across providers, bare metal and edge.
• Policy and governance - who can do what, and what is allowed to run, enforced where the workload runs.
• Application delivery - CI/CD, environments and developer self-service.

The categories map cleanly onto those layers:

• Cluster fleet managers (Spectro Cloud Palette, Rancher, Platform9) are strongest on fleet lifecycle, bare metal and edge.
• Declarative infra control planes (Crossplane, Spacelift, plus plain Terraform/OpenTofu modules) express infrastructure as code and reconcile it.
• Application delivery / internal developer platforms (Qovery, Devtron, Northflank) give developers deployments and environments.

One trap to name early: hyperscaler-native fleet tooling works well but anchors your control plane to one vendor. GKE Enterprise fleet management, Azure Arc-enabled Kubernetes and Amazon EKS Anywhere / Hybrid Nodes can each reach into other environments, but the control plane and its bill live with that vendor. If you are consolidating specifically to avoid single-vendor gravity, that is the wrong foundation.

Two requirements eliminate options faster than anything else: support for on-prem and self-managed clusters, and support for non-hyperscaler clouds like Scaleway Kapsule. Most comparison pages stop at AWS, GCP and Azure. If Scaleway Kapsule or bring-your-own-Kubernetes is in your plan, check coverage before you fall in love with a feature list.

Quick self-test before you read further: count your clusters, count your clouds, and note whether any run on-prem or at the edge. Those three numbers decide your shortlist.

Why does one platform for everything usually fail in multi-cloud Kubernetes?

The single-pane promise fails because the three layers have different owners, different change cadences and different APIs. Force one tool across all three and you write more glue than you removed. The abstraction leaks in predictable places.

Every managed Kubernetes differs underneath. Workload-to-cloud-IAM is the clearest example: EKS uses IRSA and now EKS Pod Identity, GKE uses Workload Identity Federation, AKS uses Microsoft Entra Workload ID, and Scaleway Kapsule has its own defaults. Node pools, load balancers, storage classes and CNI defaults diverge the same way. An abstraction that papers over all of that either leaks or locks you in.

Version skew is real and ongoing. Upstream Kubernetes ships roughly three releases a year, and each minor version gets about 14 months of patch support. Each provider supports a different set of minor versions at any given moment, so "the same version everywhere" is a moving target you manage continuously, not a box you tick once.

Cadence is the deeper mismatch. Cluster lifecycle changes quarterly. Application deployments change many times a day. One tool rarely serves both rhythms well, and most that try end up mediocre at the one you care about most.

A few more things worth stating plainly:

• Policy must be enforced where the workload runs - at admission, in the cluster - not only at provisioning time. A provisioning tool cannot stop a bad Pod spec from landing.
• A single pane of glass that only reads state is reporting, not control. Ask whether the tool can act or only observe. The difference is everything.
• What genuinely standardizes everywhere: container build pipelines, GitOps manifests, admission policies, environment definitions, and one RBAC model mapped to your identity provider. Standardize those, and the per-cloud differences stop mattering to your developers.

How do Crossplane, Spectro Cloud, Rancher, Platform9, Spacelift, Devtron, Northflank and Qovery compare?

Here is the verdict before the table: Spectro Cloud, Rancher and Platform9 win on cluster fleet and bare metal; Crossplane and Spacelift win on declarative infrastructure provisioning; Qovery, Devtron and Northflank win on developer-facing delivery and environments. No tool wins all three columns, which is the whole point.

Read each row in isolation and it still holds. A few gaps worth being blunt about:

• Crossplane ships no CI/CD and no developer UX. It composes infrastructure beautifully and expects you to bring everything above it. It graduated at the CNCF in October 2025, which is real evidence of maturity (CNCF).
• Spacelift orchestrates Terraform, OpenTofu, Pulumi and CloudFormation runs with OPA policy-as-code. It does not deploy applications.
• Devtron is Kubernetes-native delivery and expects you to bring clusters.
• Spectro Cloud, Rancher and Platform9 are fleet platforms, not developer self-service. They do bare metal and edge, which the delivery platforms do not.

Licensing drives budget approval, so it is in the table: Crossplane is CNCF-graduated open source; Rancher and Devtron have open-source cores; Spectro Cloud, Platform9, Spacelift, Northflank and Qovery are commercial.

Qovery's row, stated honestly: BYOC deployment into your own AWS, GCP, Azure or Scaleway account, or your existing self-managed Kubernetes cluster, with git-push deployments, preview environments per pull request, environment auto-stop, managed cluster upgrades, per-environment RBAC and databases backed by managed cloud services. It is not a bare-metal or edge fleet manager, and it does not do Crossplane-style arbitrary cloud resource composition.

The pairing I see most often in practice: Crossplane or Spectro Cloud for the fleet, plus Qovery or Devtron for delivery, with Argo CD and Kyverno underneath either way.

How do you enforce the same security policies on every Kubernetes cluster across clouds?

Identical policy across clouds comes from a Kubernetes-native admission layer (Kyverno or OPA/Gatekeeper) plus Pod Security Admission, shipped to every cluster by Argo CD or Flux. Your provisioning tool is not where policy belongs. The rules live in Git and get reconciled onto every cluster, so they travel with the workload to EKS, GKE, AKS, Kapsule or on-prem.

The concrete stack:

• Admission policy: one policy set in Kyverno or OPA/Gatekeeper, applied everywhere through GitOps. Both are mature: OPA graduated at the CNCF in 2021 and Kyverno graduated in March 2026 (CNCF).
• Pod Security Admission at the baseline or restricted level as the non-negotiable floor on every cluster (kubernetes.io).
• One RBAC model mapped to your IdP through SSO/SCIM, instead of per-cloud IAM sprawl. Per-environment RBAC is the granularity developers actually ask for.
• Network policy and secrets: pick one implementation (Cilium or Calico, External Secrets Operator) and keep it identical everywhere, or you are debugging four different failure modes.
• Drift control: cluster config and policy live in Git and are reconciled continuously by Argo CD or Flux. Both graduated at the CNCF in 2022 (CNCF), which is the practical evidence this is the default pattern and not a bet.
• Validation: run a policy conformance check per cluster in CI, so a new cluster cannot join the fleet without the same rules.

Where Qovery fits here: cluster and environment configuration live as code, and the same RBAC and deployment rules apply on every connected cluster regardless of provider. The admission layer underneath is still Kyverno or Gatekeeper, exactly as above.

How do you run the same CI/CD pipeline on every cloud without rewriting it per provider?

Keep build in your existing CI (GitHub Actions, GitLab CI) and move deploy into a cluster-agnostic delivery layer, either GitOps or a delivery platform. That separation is the only reliable way the pipeline stays identical across AWS, GCP, Azure, Scaleway and on-prem.

Build is already portable: a container image plus tests runs the same anywhere. The deploy step is what fragments per cloud, so that is the part to standardize. The anti-pattern to name and kill: eksctl in one job, gcloud in another, az aks in a third, raw kubectl apply on-prem, multiplied across every repository. That is four pipelines pretending to be one.

Two patterns actually work:

• Pattern A - GitOps. One manifest repo per cluster or per environment, reconciled by Argo CD or Flux. You own the templating (Helm, Kustomize) and the developer experience. Maximum control, maximum you-build-it.
• Pattern B - delivery platform. Declare the service and environment once, and the platform resolves cloud-specific details: ingress controller, storage class, managed database, DNS. Less control over internals, far less glue.

The acid test is preview and ephemeral environments per pull request. Fleet managers and IaC control planes do not do this. Qovery, Devtron and Northflank do. If developers need a fresh environment on every PR, that single requirement cuts your list in half.

Two more things worth standardizing once delivery is uniform:

• Progressive delivery with Argo Rollouts or Flagger behaves the same on any conformant cluster.
• Cost control becomes possible: environment auto-stop for non-production, and per-environment cost attribution. You cannot attribute what you cannot see uniformly.

What does multi-cloud Kubernetes consolidation cost, and where does it actually save money?

Consolidation saves money through fewer bespoke per-cloud pipelines and fewer idle non-production clusters, not through the tool license. The license is usually the smallest line on the page. The real money is in per-cluster control-plane fees, platform-team headcount, and what BYOC protects.

Per-cluster control-plane fees multiply with every cloud you add:

• Amazon EKS: $0.10 per cluster per hour (about $73/month) during standard support, rising to $0.60/hour in extended support (AWS).
• Azure AKS: Free tier at $0 with no SLA; Standard tier at $0.10/hour (about $73/month) with an uptime SLA; Premium at $0.60/hour (Microsoft).
• Google GKE: $0.10 per cluster per hour flat, with a $74.40/month credit that covers one zonal or Autopilot cluster (Google Cloud).
• Scaleway Kapsule: shared control plane free (etcd capped at 55 MB); dedicated control plane from about €80/month (Scaleway).

Those are small per cluster. The problem is that non-production is where clusters and nodes pile up. Across more than 2,000 organizations, Cast AI's benchmark found average CPU utilization around 8% and roughly 70% of requested CPU and memory never used, spanning AWS, Azure and GCP and both production and non-production (Cast AI). Idle dev and staging clusters and over-provisioned nodes are the waste, not the control-plane fee.

Headcount is the real line item. A platform/DevOps engineer carries a median salary around $145,000 in the US per the Stack Overflow 2025 Developer Survey, so a 2-3 person internal platform team is a six-figure annual commitment before any license. Compare that honestly against a commercial platform, not against zero.

Two honest notes on that table. The Crossplane or Spacelift path hides a cost: the developer-facing layer is still yours to build, staff and maintain, so budget it explicitly. And BYOC is a financial decision, not only an architectural one: clusters in your own accounts keep Savings Plans, committed-use discounts, enterprise agreements and negotiated rates in your name. A vendor-hosted runtime quietly moves all of that onto someone else's bill.

How should you choose? A decision checklist for 2026

If your pain is cluster count, bare metal or edge, start with Spectro Cloud, Rancher or Platform9. If your pain is developers waiting on deployments and environments, start with Qovery, Devtron or Northflank. If your team already lives in Terraform or OpenTofu, start with Crossplane or Spacelift. Then run the checklist.

• 20+ clusters including bare metal or edge: Spectro Cloud Palette, Rancher or Platform9 first.
• Infrastructure already in Terraform/OpenTofu and the team is IaC-fluent: Crossplane or Spacelift.
• Developers blocked waiting on deployments, environments or access: Qovery, Devtron or Northflank first.
• Data residency or billing must stay in your accounts: require BYOC and eliminate anything that only offers a vendor-hosted runtime.
• Existing self-managed or on-prem cluster you cannot replace: require explicit adopt-existing-cluster support. This alone removes several tools.
• Non-hyperscaler cloud in the mix (Scaleway Kapsule, OVH, Hetzner): check provider coverage before anything else, because most matrices stop at the big three.

Seven questions to ask every vendor, in order:

1. Does it adopt my existing clusters?
2. Does it handle cluster upgrades?
3. Does it do preview environments per PR?
4. Where does my cloud bill land?
5. How is policy enforced at admission time?
6. What is the self-hosted option?
7. What happens to my clusters if I stop paying?

The last one separates tools that leave you with standard Kubernetes from tools that leave you with a problem.

Why does Qovery fit the "same policies and CI/CD everywhere" requirement?

Qovery is one control plane for application delivery, environments and RBAC across AWS, GCP, Azure, Scaleway and your own existing Kubernetes cluster, with the clusters staying in your accounts. That is what it does for this problem. Now the limits, stated just as plainly: it is not a bare-metal or edge fleet manager, and it does not replace Crossplane-style arbitrary cloud resource composition.

What you get on every provider, identically:

• Git-push deployments, with preview environments per pull request.
• Environment auto-stop for non-production, and managed cluster upgrades.
• Per-environment RBAC mapped to your identity provider.
• Databases backed by managed cloud services.

Because Qovery runs inside your own cloud account or your own Kubernetes cluster (BYOC), the cloud bill, the discounts and the data stay with you. Bring-your-own-Kubernetes is what covers the hybrid and on-prem cases where a vendor-hosted runtime is simply not allowed, and Scaleway Kapsule support is why this does not collapse into a big-three-only story.

My recommendation is a pairing, not a single tool. If you run a large fleet with bare metal or edge, put Spectro Cloud, Rancher or Platform9 on the cluster layer and a delivery platform like Qovery on top, with Argo CD and Kyverno underneath both. That combination gives you one deployment workflow and one policy set on every cluster, without pretending one tool does everything.

What is the best platform to provision and manage Kubernetes clusters across AWS, GCP and Azure?

There is no single best platform for provisioning Kubernetes across AWS, GCP and Azure, because cluster lifecycle and application delivery are different jobs. For cluster fleet lifecycle, Spectro Cloud Palette, Rancher, Platform9 and Crossplane are the credible options. For one deployment and environment workflow across those clouds, Qovery, Devtron and Northflank fit better. Most teams pair one from each group.

Can one tool manage both managed Kubernetes (EKS, GKE, AKS, Scaleway Kapsule) and self-managed or on-prem clusters?

Yes, several tools adopt both managed and self-managed or on-prem clusters, but you have to check for it explicitly. Spectro Cloud, Rancher and Platform9 are built for mixed fleets including bare metal. For application delivery across managed clusters and an existing self-managed or on-prem cluster, Qovery connects to your existing Kubernetes cluster as well as to EKS, GKE, AKS and Scaleway Kapsule. Confirm Kapsule and bring-your-own-Kubernetes support specifically, since many comparison pages stop at the big three.

Is Crossplane enough on its own for multi-cloud Kubernetes consolidation?

Crossplane is enough for the infrastructure-provisioning layer, but not for the whole problem. It composes cloud resources as Kubernetes APIs and graduated at the CNCF in 2025, yet it ships no CI/CD and no developer experience. To consolidate fully you still add an admission layer (Kyverno or OPA), GitOps (Argo CD or Flux), and a developer-facing delivery layer, all of which are yours to build and staff.

How do Qovery, Devtron and Northflank differ for multi-cloud application delivery?

Qovery, Devtron and Northflank all deliver applications and preview environments across clouds, but they differ on runtime location. Qovery is BYOC-first: it runs inside your own AWS, GCP, Azure or Scaleway account or your existing Kubernetes cluster, so the bill and discounts stay with you. Devtron is Kubernetes-native delivery with an open-source core and expects you to bring clusters. Northflank is a platform-as-a-service with managed and BYOC options.

How do you enforce identical security policies on Kubernetes clusters running in different clouds?

You enforce identical security policy with a Kubernetes-native admission layer applied by GitOps, not with your provisioning tool. Use Kyverno or OPA/Gatekeeper for admission control, Pod Security Admission as the baseline floor, and Argo CD or Flux to reconcile the same policy set onto every cluster. Because the rules live in Git and run at admission inside each cluster, they apply the same way on EKS, GKE, AKS, Kapsule and on-prem.

Does consolidating onto one Kubernetes control plane actually reduce cloud costs?

Consolidating reduces cost mainly by removing bespoke per-cloud pipelines and idle non-production clusters, not through the license. Per-cluster control-plane fees are small (about $73/month on EKS, AKS Standard and GKE), but Cast AI found roughly 70% of requested CPU and memory goes unused across thousands of organizations, and non-production is where that waste concentrates. Uniform delivery makes environment auto-stop and per-environment cost attribution possible, which is where the savings actually land.