How Kubernetes Teams Split Workloads Between Public Cloud and a Private Cloud

Kubernetes was built to make applications less dependent on the infrastructure underneath them. The same manifests, Helm charts, and deployment pipelines work whether a cluster runs on a managed service like Amazon EKS or on virtual machines in a private cloud. That’s what makes it practical to split workloads: steady services can run where compute is cheaper and more predictable, while workloads that genuinely benefit from public cloud stay there, all managed the same way.

Here’s the situation that usually starts it: A team runs everything on EKS. The bill grows month after month, and most of it comes from services that run around the clock at a predictable level: APIs, background workers, internal tools. Those are exactly the workloads that cost less on dedicated infrastructure. But the team also has workloads that make sense in AWS, like services tied closely to managed AWS products or traffic that spikes unpredictably.

Moving everything isn’t the goal. Moving the right things is. Kubernetes makes that possible, as long as you plan for the places where clusters differ.

Why Kubernetes Makes Splitting Practical

A Kubernetes workload is described by its manifests: deployments, services, config, and secrets. Those manifests talk to the Kubernetes API, not to the cloud underneath. So the same application definition can be deployed to a cluster in AWS and a cluster in a private cloud with only a few environment-specific changes.

The differences live at the edges, where Kubernetes hands off to the infrastructure:

• How services get load balancers
• Where persistent volumes come from
• How workloads authenticate to cloud resources
• How nodes are created and scaled

Plan for those, and the rest of your application moves with it.

Split Patterns That Work

Steady Services on Private, Spiky Workloads on Public

Services that run at a consistent level all month use dedicated capacity efficiently, so they’re the strongest candidates for a private cloud. Workloads that spike briefly and sit idle the rest of the time often cost less on usage-based pricing and can stay in public cloud.

Data-Heavy Services on Private, Edge-Facing Services on Public

Services that read or write large volumes of data, such as databases, analytics pipelines, and media processing, often benefit from dedicated hardware and from not paying per GB to move data out. Services that need presence in many regions close to users can stay where that footprint already exists.

Development, Test, and CI on Private

Non-production clusters run constantly, get rebuilt often, and rarely need the reach of a public cloud. Moving them to a private cloud is often a low-risk way for a team to learn the new platform before moving production.

Per-Customer Clusters on Private

Teams that run a dedicated cluster or namespace for each large customer often add capacity every time they sign one. Predictable per-server pricing makes that growth easier to plan and price.

Services Built Around Managed Services Stay Close to Them

If a workload depends heavily on a managed queue, database, or AI service in AWS, keep it near that service until the dependency changes. Splitting it from the service it calls constantly creates cross-cloud traffic and latency.

What Differs Between Clusters

Load Balancers

On EKS, Kubernetes services of type LoadBalancer are backed by AWS load balancers. On an OpenStack private cloud, the OpenStack cloud controller manager provides the same function using Octavia, OpenStack’s load balancing service.

One detail matters on OpenMetal. New Private Cloud Core v4 deployments use OVN networking by default, and with OVN, Octavia provides Layer 4 TCP and UDP load balancing. Layer 7 features like TLS termination and routing by hostname or path aren’t available from the OpenStack load balancer on an OVN cloud. For most Kubernetes setups that’s not a problem: you run an ingress controller inside the cluster to handle TLS and routing, and put an Octavia load balancer in front of it to pass TCP traffic through. Our guide to choosing between OVN and OVS before your private cloud deploys covers the tradeoffs.

Persistent Storage

On EKS, persistent volumes typically come from EBS. On an OpenStack private cloud, the Cinder CSI plugin from the same cloud-provider-openstack project provisions volumes from Cinder, which on OpenMetal is backed by Ceph. Your applications request storage the same way, through persistent volume claims and storage classes. The storage class names and parameters differ per cluster, so keep them in environment-specific configuration.

Moving the data itself is a separate step. Plan it like any data migration, with a sync and a cutover.

Identity and Access

Workloads on EKS often use AWS-specific mechanisms to reach AWS services without stored credentials. A workload on a private cloud that still needs AWS services will need another way to authenticate. Inventory these dependencies early. They’re often the part of a workload that’s hardest to move.

Nodes and Scaling

On EKS, node groups are managed through AWS. On a private cloud, you create worker nodes as VMs, or as bare metal servers when a workload needs full hardware, and you manage the cluster with your choice of tooling. Capacity planning shifts from per-instance decisions to how much dedicated hardware you keep available.

Container Images

If your images live in a registry in AWS, a cluster in your private cloud pulls them across the internet. That’s data leaving AWS on every pull. Consider a registry closer to the private cloud cluster, or mirror the images it uses most.

Keeping Clusters Consistent

Running clusters in two places works well when the same process deploys to both.

Use One Source of Truth

GitOps tools such as Argo CD and Flux deploy from a Git repository to many clusters. Keep shared application definitions in one place and environment-specific settings, like storage classes, load balancer annotations, and replica counts, in per-cluster overlays.

Standardize the Platform Layer

Install the same ingress controller, certificate management, policy engine, and monitoring stack on every cluster. Differences should be limited to the infrastructure integrations covered above.

Watch Everything From One Place

Send metrics and logs from every cluster to one observability stack, so a problem on either side shows up in the same dashboards and alerts.

Connecting the Clusters

Keep Cross-Cluster Calls Rare

Every request between a cluster in AWS and a cluster in your private cloud crosses a network boundary, adds latency, and, in one direction, adds AWS data transfer charges. Design the split so services that talk constantly sit in the same cluster. Our article on what hybrid cloud networking actually costs explains how direction affects the bill.

Plan Addresses Before You Connect

Clusters bring their own pod and service ranges. If those overlap with networks on the other side of the connection, traffic won’t route correctly. Our article on what overlapping IP ranges break when you connect a private cloud to AWS covers how to plan them.

Choose the Connection

A site-to-site VPN between your private cloud and your VPC is the usual starting point. For services that only need to be reachable publicly, an authenticated public endpoint can be simpler than a private connection.

Running Kubernetes on OpenMetal

On OpenMetal, you can run Kubernetes clusters on VMs in a hosted private cloud, use bare metal servers for workers that need full hardware, or combine both on one private network. Clusters on the private cloud use the OpenStack cloud controller manager for load balancers and the Cinder CSI plugin for Ceph-backed volumes. Our Kubernetes workloads page covers the options in more detail.

How a Deployment Works

When a Kubernetes team moves workloads to OpenMetal, the process follows a consistent shape:

• We plan ahead. We scope the environment around the workloads you’re moving, plan capacity for your clusters, and source and stage the hardware against your go-live date.
• You decide. You choose which workloads move first, how your clusters are laid out, which networking backend your private cloud uses, and how you’ll cut over.
• We hand over. You get a running private cloud with full admin access and a private Slack channel with our engineers. For migrations, ramp pricing and running old and new environments in parallel during cutover are available.

Who This Is For

This approach fits teams that:

• Run Kubernetes in public cloud and see steady services driving most of the bill
• Already deploy with Helm, GitOps, or a consistent pipeline
• Want to move workloads gradually rather than all at once
• Run per-customer or per-team clusters that grow with the business

It’s harder if you:

• Depend heavily on cloud-specific integrations inside most workloads
• Don’t yet have a repeatable way to deploy to a second cluster
• Run mainly short-lived or highly spiky workloads

The Short Version

Kubernetes gives you the same API on both sides, so splitting workloads is a matter of deciding what goes where and planning for the edges: load balancers, storage, identity, and nodes. Put steady services on the private cloud, keep the rest where it fits, and deploy to both from one source of truth.

To see how your workloads run on a Kubernetes cluster in an OpenMetal private cloud, apply for a proof of concept or talk with our team. You can also size a cluster with our private cloud pricing calculator.

Frequently Asked Questions

Can I run the same Kubernetes manifests on EKS and a private cloud?

Mostly, yes. The application definitions work the same way. The differences are in infrastructure integrations like load balancer annotations, storage classes, and cloud credentials, which you keep in per-cluster configuration.

How do Kubernetes load balancers work on an OpenStack private cloud?

The OpenStack cloud controller manager creates load balancers through Octavia. On an OpenMetal private cloud using OVN networking, Octavia provides Layer 4 load balancing, so TLS termination and HTTP routing are handled by an ingress controller inside the cluster.

Where do persistent volumes come from on OpenMetal?

The Cinder CSI plugin provisions volumes from Cinder, which is backed by Ceph on OpenMetal private clouds.

Which Kubernetes workloads should move to a private cloud first?

Steady, always-on services and non-production clusters are usually the best starting points. Workloads tied closely to managed AWS services or with very spiky usage often fit better where they are.

How do I keep clusters in two environments consistent?

Deploy from one Git repository with a GitOps tool like Argo CD or Flux, keep environment-specific settings in per-cluster overlays, and standardize the platform tools installed on every cluster.

Does splitting clusters increase network costs?

It can. Traffic from AWS to your private cloud is billed as AWS data transfer out. Keep services that talk constantly in the same cluster, and keep frequently pulled data and images close to the cluster that uses them.