Perspectives, mises à jour et histoires de notre équipe
Navos runs on unmodified upstream Kubernetes and Cluster API. Learn why that architectural choice matters for portability, multi-cloud, and no-lock-in cluster management.
OpenStack controls infrastructure. Kubernetes orchestrates workloads. For AI, you need both. Learn why the combination delivers what neither can alone.
Hardware cycles are accelerating, regulations are multiplying, and costs are rising. A framework for AI infrastructure decisions that last through 2031.
OpenStack controls infrastructure. Kubernetes orchestrates workloads. For AI, you need both. Learn why the combination delivers what neither can alone.
For AI infrastructure, OpenStack and Kubernetes solve different problems at different layers of the stack.
Kubernetes orchestrates containerized workloads. It handles scheduling, scaling, deployment, and lifecycle management for applications.
OpenStack provides the underlying infrastructure. It manages compute, networking, storage, GPUs, and the physical resources those workloads depend on.
AI workloads require both. GPUs must be provisioned, isolated, and connected to high-performance storage and networking. At the same time, AI applications need workload scheduling, automation, and portability across environments.
Together, OpenStack and Kubernetes provide a complete platform for AI infrastructure: OpenStack delivers the infrastructure foundation, while Kubernetes orchestrates the workloads running on top of it. This architecture enables organizations to build private, public, or hybrid AI clouds using open technologies rather than proprietary platforms. OpenStack today powers more than 55 million CPU cores in production worldwide, while Kubernetes has become the de facto standard for container orchestration across the industry.
This post explores the role of each layer, why modern AI platforms increasingly rely on both, and how Atmosphere by VEXXHOST combines OpenStack and Kubernetes into a unified platform for AI, cloud-native applications, and private cloud infrastructure.
The confusion between OpenStack and Kubernetes comes from treating them as the same category. They're not. They operate at different layers and answer different questions.
OpenStack answers: what infrastructure exists and who controls it?
Compute provisioning. GPU allocation. Storage placement. Network topology. Identity and access management. OpenStack manages physical and virtual resources across regions and availability zones through open APIs. It determines where resources live, how they're configured, and who has access.
Kubernetes answers: how do workloads run on that infrastructure?
Pod scheduling. Autoscaling. Service discovery. Job management. Rolling deployments. Kubernetes orchestrates containers across available resources through declarative, CNCF-standard APIs. It determines how applications are deployed, scaled, and moved.
OpenStack doesn't schedule pods. Kubernetes doesn't allocate GPUs at the hardware level. OpenStack doesn't manage rolling deployments. Kubernetes doesn't control network fabrics or storage placement.
They don't overlap. They complete each other.
For a broader look at how this layered approach is shaping cloud architecture, read OpenStack, Kubernetes, and AI: What 2025 Taught Us About the Future of Cloud.
Traditional cloud workloads (web apps, APIs, microservices) can run on Kubernetes alone without much concern for what's underneath. The infrastructure layer is mostly invisible.
AI workloads don't have that luxury. They're infrastructure-sensitive in ways that standard workloads aren't.
Training needs multi-node GPU clusters with high-bandwidth networking between them. Which GPUs, on which nodes, connected by which fabric, with storage placed where? These are infrastructure decisions that directly affect how fast training completes. Kubernetes can schedule the job. It can't control the GPU topology, network path, or storage locality beneath it.
Inference needs low-latency serving at scale with efficient GPU utilization. A single inference endpoint might need a fractional GPU through MIG while another needs full passthrough. That flexibility lives at the infrastructure layer, not the orchestration layer.
AI agents need persistent state, always-on compute, and real-time inter-service communication. The orchestration is Kubernetes. The networking, storage persistence, and compute allocation is OpenStack.
Every AI workload type depends on decisions being made correctly at both layers simultaneously. Kubernetes without infrastructure control means you're scheduling workloads blind. OpenStack without workload orchestration means you're managing infrastructure manually.
For AI, both layers aren't optional. They're load-bearing.
For more on how different AI workload types place different demands on infrastructure, read AI Workloads on Kubernetes: Training vs. Inference Infrastructure.
OpenStack gives you direct control over the physical and virtual resources that AI workloads depend on. Without it, these decisions get made for you by a provider, inside a black box.
GPU allocation. Nova supports GPU passthrough for full hardware performance, vGPU for shared access, and MIG for fractional allocation. You choose the mode that fits the workload, not the mode the provider offers.
Topology-aware placement. NUMA-aware scheduling, CPU pinning, and hardware-level placement ensure workloads land on the right processors and memory. For AI, this is the difference between predictable performance and unexplained latency.
Storage. Ceph integrates directly with OpenStack, providing scalable block and object storage deployed alongside compute. Data stays local to GPUs. No egress penalties. No proprietary formats.
Networking. SR-IOV for near-bare-metal performance. DPDK for accelerated packet processing. Full control over network topology, segmentation, and bandwidth, up to 100Gbps. Distributed training depends on this layer being fast and configurable.
Multi-tenancy. OpenStack projects, quotas, and identity management let multiple teams share GPU infrastructure with proper isolation and cost attribution without stepping on each other.
None of this is visible or controllable when Kubernetes runs directly on a hyperscaler. These capabilities exist only when the infrastructure layer is open.
For more on what makes infrastructure AI-ready at a practical level, read How to Evaluate Whether Your Infrastructure Is AI-Ready.
OpenStack makes the infrastructure available. Kubernetes puts it to work.
GPU-aware scheduling. Kubernetes assigns GPU resources to pods based on workload requirements, topology, and availability. Jobs land on the right nodes — not just available nodes.
Declarative workload definitions. Training jobs, inference endpoints, and batch processes are defined as code. Reproducible, version-controlled, and portable across any conformant Kubernetes cluster.
Autoscaling. Inference endpoints scale with demand — up when traffic spikes, down when it drops. Horizontal pod autoscaling and custom metrics keep GPU utilization high without manual intervention.
Job management. Training runs, fine-tuning tasks, and batch processing are managed as Kubernetes jobs with scheduling priorities, retry logic, and resource quotas. Multiple teams can share the same cluster without contention.
The CNCF ecosystem. Prometheus for monitoring. Grafana for dashboards. Argo for workflows. Kubeflow for ML pipelines. Kubernetes connects to the largest open-source tooling ecosystem in infrastructure; all through standard APIs.
Portability. Workloads defined on upstream Kubernetes can move between environments (on-premise, cloud, hybrid) without re-engineering. The orchestration layer stays consistent regardless of what's underneath.
But that portability only holds when the infrastructure beneath Kubernetes is also open. On a hyperscaler, Kubernetes runs inside a proprietary environment. The pods are portable in theory: the storage, networking, and GPU configuration holding them in place are not.
For more on why upstream Kubernetes matters for long-term portability, read Running Kubernetes in 2026.
Each platform is powerful on its own. But for AI workloads, running one without the other leaves critical gaps.
Kubernetes without OpenStack: You get workload orchestration, but on infrastructure you don't control. GPU allocation is filtered through proprietary instance types. Networking is abstracted away. Storage is whatever the provider offers. Multi-tenancy is limited to what the managed control plane exposes. You can schedule pods efficiently, but you can't control what's underneath them. The orchestration is portable. The infrastructure dependency is not.
OpenStack without Kubernetes: You get full infrastructure control, but workload management becomes manual. Scheduling GPU jobs across nodes, scaling inference endpoints, managing rolling deployments, handling resource quotas across teams, all of this requires custom tooling or operational overhead that Kubernetes handles natively. You control the hardware. But operating AI workloads at scale on it becomes unnecessarily complex.
The gap is symmetrical. Kubernetes needs infrastructure visibility to schedule AI workloads intelligently. OpenStack needs workload orchestration to make AI infrastructure operational. Remove either layer and something essential breaks: control or usability.
This is why the "OpenStack vs. Kubernetes" framing was always misleading. The real question for AI was never which one. It was always how to run them together.
Atmosphere by VEXXHOST doesn't run OpenStack alongside Kubernetes. It integrates them. OpenStack runs on top of Kubernetes.
Kubernetes manages the platform lifecycle. OpenStack manages the infrastructure. Kubernetes also orchestrates the workloads on top. Both layers are upstream OpenStack Powered certified, CNCF Kubernetes certified. No forks. No vendor extensions.
For AI, this means GPU passthrough, MIG, and vGPU managed through OpenStack and exposed to Kubernetes pods with full topology awareness. Ceph storage accessible to VMs and containers. SR-IOV and DPDK networking available to distributed training workloads. Multi-tenancy through OpenStack projects mapped to Kubernetes namespaces.
Two layers, one platform. Deploy on-premise, colocation, or hosted. The architecture stays the same. For a full overview, read The Complete Guide to Managed OpenStack with Atmosphere.
OpenStack controls the infrastructure. Kubernetes orchestrates the workloads. One without the other leaves a critical gap, either you lose control or you lose usability.
Together, they deliver full-stack, open AI infrastructure where every layer is visible, controllable, and portable. That's what Atmosphere is built on.
Explore Atmosphere — where both layers work as one.
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes