Kubernetes on OpenStack: Modern Container Infrastructure for Enterprise Workloads

Kubernetes is the backbone of cloud-native application delivery. OpenStack provides the ideal infrastructure substrate for Kubernetes clusters. VM2Cloud delivers Kubernetes on OpenStack with optimized compute, networking, and Ceph-backed storage.

Why Run Kubernetes on OpenStack?

• Consistent VM & Bare Metal infrastructure for Kubernetes nodes
• Persistent storage via Ceph RBD
• Magnum integration for cluster lifecycle
• Load balancers powered by Octavia
• Support for GPU workloads & AI pipelines

VM2Cloud Kubernetes Architecture

HA control planes, worker node autoscaling, integrated CNI networking, storage classes, and enterprise-grade monitoring.

How Kubernetes Uses the Cloud Underneath

Kubernetes schedules containers, but it still needs machines, networks and disks to run on. On OpenStack those come from the cloud APIs: Nova supplies the virtual machines that serve as control-plane and worker nodes, Neutron supplies the networks, and Cinder supplies persistent volumes. Because each of these is requested through an API, a cluster can be created, grown and replaced by automation.

The OpenStack Services Involved

• Magnum manages the lifecycle of Kubernetes clusters, such as creating, scaling and deleting them.
• Octavia provides load balancers, so a Kubernetes Service of type LoadBalancer can get an address from the cloud.
• Cinder provides block volumes, which Kubernetes can use as persistent volumes through a CSI driver.
• Neutron provides the tenant networks, routers and security groups the nodes sit on.
• Keystone provides the identity and projects that cluster resources belong to.

Storage for Stateful Workloads

Stateful applications need volumes that outlive any single pod. A pod asks for storage through a persistent volume claim, which names a storage class, and a CSI driver then creates the volume and attaches it to the node where the pod runs. With the OpenStack Cinder CSI driver, each storage class names a Cinder volume type, so a cluster can offer more than one storage tier and each workload can ask for the one it needs.

Networking and Load Balancing

Every Kubernetes cluster needs a CNI plugin for pod networking. Traffic from outside the cluster can reach a service through an Octavia load balancer. Security groups on the underlying instances add a second layer of control beneath Kubernetes network policy.

GPU Worker Nodes

In OpenStack, GPUs reach instances through flavors, once the cloud operator has configured PCI passthrough or virtual GPUs on hosts that have the hardware. Worker nodes built from such flavors can form a separate node group in a Kubernetes cluster. With the GPU drivers and the Kubernetes device plugin installed, pods that request a GPU are scheduled onto those nodes, and taints can keep general workloads on ordinary nodes. Training data and model files are commonly kept in object storage that speaks the S3 API.

Planning a Cluster Design

• How many clusters do you need, and should environments such as test and production be separate?
• Which workloads are stateful, and which storage tiers do they need?
• Do any workloads need GPUs?
• How will clusters be created: through Magnum, or through your own automation tools?
• What monitoring and upgrade routine will keep the clusters current?

Request a Kubernetes Architecture Call

Our engineers can design a Kubernetes environment optimized for your application ecosystem.