Most Kubernetes deployments across Gulf region enterprises are running on VMware — which made sense for years but is increasingly awkward as Broadcom's licensing changes force infrastructure re-evaluation. OpenShift on Nutanix changes the conversation in a meaningful way.
Nutanix AHV is a Type-1 hypervisor that has been quietly becoming very capable. When you run OpenShift on top of it, you get a container platform where the underlying infrastructure is also software-defined, policy-driven, and centrally managed from Prism Central. That's a different operational posture than running Kubernetes on bare metal or on separate VMware clusters.
What the architecture looks like
At its simplest: Nutanix nodes running AHV, OpenShift control plane and worker nodes as VMs on top, with Nutanix providing storage via the CSI driver. The CSI integration is what makes this genuinely useful — persistent volumes are backed by Nutanix volume groups or files, inheriting the same data protection and snapshot capabilities as everything else on the cluster.
For production deployments the architecture typically looks like:
- 3x control plane nodes distributed across failure domains
- Worker nodes sized to workload — GPU workers on separate node pools if needed
- Nutanix CSI Driver for persistent storage — volumes and files
- Nutanix Flow for microsegmentation of pod-to-pod traffic
- MetalLB or NSX-T for load balancer services
What actually changes operationally
The thing that catches teams off guard isn't the Kubernetes layer — it's how Nutanix AHV handles VM snapshots and what that means for stateful workloads. AHV crash-consistent snapshots of the OpenShift worker VMs are not a substitute for application-consistent backup of Kubernetes persistent volumes. Those need to be handled through the CSI snapshot interface or an external tool like Kasten or Trilio.
The platform simplifies a lot, but it doesn't eliminate the need for a proper data protection strategy at the application layer.
The network side is where most teams underestimate complexity. OpenShift has its own SDN (OVN-Kubernetes by default) running on top of whatever the underlying network is. When Nutanix Flow is also in play, you need a clear mental model of which layer is enforcing which policy — otherwise troubleshooting becomes very painful.
Where the edge cases are
- IPI vs UPI installation: Nutanix now supports Installer-Provisioned Infrastructure (IPI) for OpenShift. Use it. UPI works but the day-2 operational overhead is significantly higher.
- NTP alignment: AHV nodes, Prism Central, and OpenShift nodes all need tight NTP synchronisation. Drift causes certificate validation failures that are difficult to diagnose.
- Resource reservation: AHV's default memory overcommit settings will cause issues with OpenShift's QoS guarantees. Reserve memory for control plane nodes explicitly in Prism.
- Storage class defaults: Define your storage classes carefully from day one. Retrofitting storage class annotations to existing PVCs in large deployments is time-consuming.
Is it worth it?
For organisations already running Nutanix for VM workloads — yes, almost certainly. The operational benefit of managing infrastructure from a single control plane (Prism Central) outweighs the complexity of the CSI and Flow integration. The alternative of maintaining a separate Kubernetes-specific infrastructure layer is almost always harder to justify to operations teams.
Planning an OpenShift deployment on Nutanix? Get in touch.