Skip to content

Blog

Managed Kubernetes on your own cloud account is now on 5 clouds

By Nathan McNeill5 min read
Managed Kubernetes on your own cloud account is now on 5 clouds

Until about a year ago, if you wanted Control Plane to manage Kubernetes on your own cloud account, we only supported AWS. Managed Kubernetes is now available on AWS, GCP, Azure, Akamai Cloud (Linode), and Hetzner.

It’s the same core API and operational model across providers, with a consistent workflow for upgrades, networking, and observability. Provider-specific infrastructure configuration and available add-ons vary by cloud. This post walks through what that means, what the platform handles for you on each provider, and what shipped along the way.

About Control Plane’s Managed Kubernetes

With Control Plane Managed Kubernetes, you bring a cloud account that you own and pay for, and Control Plane stands up, operates, and continuously manages a Kubernetes cluster inside it.

You get a real Kubernetes cluster — you can run kubectl against it, install Helm charts, deploy your own operators, and use any Kubernetes API. Control Plane handles the parts that take a platform team to do well: control-plane management, node provisioning, version upgrades, networking, identity, observability, storage classes, and the constellation of add-ons that turn a bare Kubernetes cluster into something you can actually run production workloads on.

Because the cluster runs in your account, your AWS commit (or GCP, Azure, Linode, or Hetzner spend) is what the underlying compute burns down. Your worker infrastructure runs in your cloud account, so eligible provider usage may count toward your existing cloud commitments, subject to your provider agreement. Optional observability add-ons send selected metrics, pod logs, and Kubernetes audit records to Control Plane for centralized monitoring and analysis.

What stays the same as the cloud underneath changes

The core Control Plane management surface is consistent across providers:

  • Same core API. Clusters, node pools, identities, policies, and workloads are managed through the same Control Plane API and top-level resource model. Provider-specific infrastructure fields—such as instance types, networks, subnets, regions, and cloud credentials—vary by cloud.
  • Same operational model. Cluster lifecycle, version upgrades, add-on management, observability, secret rotation — one workflow for all of it.
  • Same tooling. Use the UI, API, CLI, Terraform / OpenTofu / Pulumi / Helm, and MCP across providers, with provider-specific configuration where required.
  • Same audit trail and identity model. Cluster operations are logged in the same tamper-proof audit trail, attributed to the same identities, governed by the same policies.

A platform engineer who learned to operate Control Plane Managed Kubernetes on AWS already knows how to operate it on Hetzner and any provider we support.

What the platform handles for you on every provider

Cluster auto-scaling — automatic node provisioning

When workloads need more capacity than the existing nodes can serve, the cluster autoscaler provisions new nodes automatically — EC2 instances on AWS, Compute Engine VMs on GCP, equivalent VMs on Azure, Linode, and Hetzner. When demand drops, surplus nodes are removed, so charges for those compute instances stop. Persistent storage, networking resources, minimum node counts, and other provider charges may remain.

Node-pool refresh and version upgrades

Kubernetes version bumps, OS patches, credential rotations, certificate provisioning — all handled by the platform on a rolling basis. Node-upgrade activity is logged in the audit trail, and the platform tracks upstream Kubernetes releases.

Networking

A service mesh ties workloads together across regions, mutual TLS by default. Calico and Cilium are supported Kubernetes networking options, while Istio provides the service-mesh layer. These components receive regular upgrades. Optional IPv6 endpoints in some GCP locations. DNS forwarder configuration across all providers.

Observability and add-ons

A cluster dashboard reachable from the Metrics link in the UI. Grafana add-ons including Sentry, Cloudflare, and GCP Logging data sources. Headlamp as an optional add-on for cluster visualization.

Storage

Managed Kubernetes handles provider-specific storage classes. AWS supports customer-managed KMS encryption and custom ephemeral-disk device identifiers. Control Plane platform volume features include volume shrinking, predictive volume-set scaling, and concurrent expand/snapshot operations. Shared volumes can be enabled through the CPLN Platform add-on.

Multi-architecture (ARM64 + x86)

Platform-wide multi-architecture support. Control Plane supports ARM64 and x86 where the selected provider and node type offer them. ARM instances can improve price-performance for compatible workloads, depending on the provider, region, instance type, and workload.

AWS-specific enhancements

Beyond the multi-cloud parity, AWS picked up three additions that matter for particular kinds of workloads:

  • Bare-metal instance types — for performance-sensitive workloads that don’t want a virtualization layer between them and the hardware, or for workloads that need to run their own VMs.
  • Nested virtualization — useful for KVM-based isolation, security sandboxes, and development environments that need full VM semantics inside a cluster node.
  • Customer-managed KMS encryption for node disks — for security teams that need to hold the encryption keys themselves rather than relying on AWS defaults.

If a previous evaluation hit one of these specific requirements, it’s worth re-testing.

Bring your own cluster — BYOK

If you already have a compatible Kubernetes cluster—such as EKS, GKE, AKS, K3s, OKE, or upstream Kubernetes—you can integrate it as a Control Plane BYOK location for managed workload deployment rather than provisioning a new Managed Kubernetes cluster.

Automatic discovery is documented for Linode LKE. Other compatible clusters can be integrated through the standard BYOK installation flow. Control Plane manages workloads deployed to the BYOK location, while the existing provider or operator continues to manage the underlying cluster infrastructure and lifecycle.

Try it

Provider-specific guides and configuration live in the Managed Kubernetes documentation. For Bring-Your-Own-Kubernetes setups, start with the CPLN Platform / BYOK overview.

Further reading

Managed Kubernetes overview

Bring-Your-Own-Kubernetes overview

Release notes, January 2025 (Azure Managed Kubernetes)

Release notes, August 2025 (GCP GA, Autoscaler Expanders)

Release notes, October 2025 (cluster dashboard, AWS volume KMS)

Release notes, January 2026 (Hetzner)

Release notes, February 2026 (AWS bare-metal, nested virtualization, KMS)Release notes, April 2026 (K8s 1.35, Cilium, in-place vertical scaling)