OpenStack, Kubernetes & public cloud · Prasanta Kumar Behera

Where OpenStack fits next to Kubernetes and public cloud, and how they combine: running Kubernetes on OpenStack with the OpenStack cloud controller manager, Cinder CSI and Octavia load balancers, cluster provisioning with Magnum or Cluster API, and choosing the right platform per workload.

Three platforms, different trade-offs

	OpenStack (private IaaS)	Kubernetes	Public cloud (AWS etc.)
Unit	VMs, networks, volumes	Containers/pods	VMs plus hundreds of managed services
You operate	The whole cloud, hardware to APIs	The clusters (or use managed)	Only your usage
Strengths	Control, data locality, steady cost at scale, special hardware	Application packaging, scaling, self-healing	Speed, breadth, elasticity, global reach
Weak spots	Operating effort, fewer managed services	Needs infrastructure underneath	Cost at steady scale, data residency limits

They're layers, not rivals: Kubernetes usually runs on OpenStack VMs, on public-cloud VMs, or on bare metal.

OpenStack is owning your own building, Kubernetes is the way you arrange furniture and rooms inside any building, and public cloud is renting a serviced office. You can arrange rooms the same way in your own building or a rented one; which building is better depends on how many people you have, how long you'll stay, and what special equipment you need.

Kubernetes on OpenStack

The integration pieces, all from the cloud-provider-openstack project:

Component	What it does
openstack-cloud-controller-manager (OCCM)	Node addresses, removing deleted nodes, and `Service type: LoadBalancer` → Octavia load balancer
Cinder CSI	PVCs → Cinder volumes (attach, expand, snapshot)
Manila CSI	Shared filesystems (RWX) from Manila, if deployed
Keystone auth webhook (optional)	Kubernetes authentication with Keystone tokens

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cinder-ssd
provisioner: cinder.csi.openstack.org
parameters:
  type: ssd                       # a Cinder volume type (lesson 05)
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Plan for the extra hops. A Cinder volume must attach to the node VM before the pod starts, and a LoadBalancer Service creates Octavia amphora VMs, which takes minutes on some clouds. Remember MTU too: pod overlays inside tenant overlays need a smaller MTU again (see Networking Deep Dive, lesson 01).

Provisioning clusters

Magnum: an OpenStack service that creates Kubernetes clusters from cluster templates (openstack coe cluster create). Recent deployments often back it with a Cluster API driver.
Cluster API with CAPO: declarative clusters as Kubernetes objects (see Cluster Design); CAPO creates networks, servers and load balancers on OpenStack.
Terraform + a distro installer (kubeadm, RKE2): straightforward and common for platform teams.

Hybrid in practice

Keep identity, CI/CD, GitOps and observability the same across private and public clusters, so workloads can move.
Use Terraform for both OpenStack and AWS resources, and one GitOps repo for clusters everywhere.
Burst to public cloud only if the data and network paths allow it; egress and latency often decide.

Try it: Kubernetes on your lab cloud

Boot three instances on your Kolla lab (or any OpenStack you can access) and install Kubernetes with kubeadm or k3s.
Install openstack-cloud-controller-manager and Cinder CSI with an application credential (lesson 02) in their cloud config.
Create the cinder-ssd StorageClass, a PVC and a pod; watch the volume appear in openstack volume list and attach to the node.
If Octavia is deployed, create a LoadBalancer Service and watch openstack loadbalancer list.
Write one paragraph: which of your workloads belong on OpenStack, on public cloud, or either, and why.

Going deeper: platform choices

Compare total cost honestly: hardware, power, space, licences, people, versus public cloud bills at your actual utilisation.
Keep bare-metal Kubernetes (Metal3, Tinkerbell, EKS Anywhere; see Edge Kubernetes & Zero-Touch Provisioning) in mind for workloads that don't need a VM layer at all.
Design for portability only where it pays off: standard Kubernetes APIs travel well; heavy use of one cloud's managed services doesn't.

Recap

OpenStack, Kubernetes and public cloud are layers with trade-offs, not rivals.
On OpenStack, Kubernetes uses OCCM (nodes and Octavia load balancers) and Cinder CSI (volumes).
Provision clusters with Magnum, Cluster API (CAPO) or Terraform plus an installer.
For hybrid: same identity, GitOps and observability everywhere; choose per workload on data, cost and latency.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.