Introduction
You may (or may not) be aware that for the past few years Kubernetes® hasn’t just been for stateless web servers. These days, organizations are running their most critical stateful workloads, such as databases, data streaming platforms, and AI pipelines, directly in production Kubernetes environments. However, as cloud-native applications have matured, a glaring operational gap has emerged. Standard Kubernetes Container Storage Interfaces (CSI) are essentially "dumb." They know how to provision a disk, but they have no concept of application SLAs, holistic disaster recovery, or cross-cluster mobility. To solve this, organizations often resort to bolting on complex software overlays that eat up expensive Kubernetes compute, or they drag modern cloud-native apps backward into legacy 3-tier hardware architectures.
Enter Nutanix Data Services for Kubernetes (NDK). NDK fundamentally solves the stateful Kubernetes problem by providing application-aware disaster recovery, cloning, and mobility. But here’s the thing: if you look under the hood, NDK isn’t doing the heavy lifting alone. NDK is the "brains" of the operation, translating Kubernetes YAML and application state. The true "brawn" making it all possible is Nutanix Unified Storage (NUS). Here is why the combination of NUS and NDK delivers an exceptional foundation for your cloud-native data strategy.
One-Click Simplicity: Enabling NDK via the Nutanix Kubernetes Platform (NKP) App Catalog
The "Overlay-Free" Architecture: Eliminating the Kubernetes Tax
Alternative approaches to Kubernetes storage often rely on heavy software overlays. They run data replication, compression, and snapshotting inside user-space containers directly on your Kubernetes worker nodes. This steals (or borrows if we’re being nice) vital CPU and RAM from your actual mission-critical applications.
Since NDK is built to partner natively with NUS, it takes a completely different approach. NDK acts as the Kubernetes control plane, but it offloads all heavy data operations directly to the underlying NUS storage fabric. Your Kubernetes worker nodes dedicate 100% of their compute power to running your applications. The underlying NUS platform handles the enterprise storage services, giving you high performance without the "Kubernetes tax" of software overlays or the operational nightmare of managing fragmented external infrastructure.
The Cloud-Native Storage Triad: Block, File, and Object
Modern cloud-native applications are diverse. A modern Retrieval-Augmented Generation (RAG) AI pipeline, for example, needs three entirely different storage protocols to function. NUS delivers all three from a single platform, natively to Kubernetes:
- Block (RWO) for Data Ingestion: High-throughput streaming platforms like Kafka, which ingest live production data into the AI pipeline so it can ultimately be converted into dense vectors, rely on the ultra-low latency of Block storage. Nutanix Volumes (a pillar of NUS) natively delivers this ReadWriteOnce performance.
- Object for Vector Databases and Registries: Stateful vector databases like Milvus are built to leverage an S3-compatible backend to handle massive scale. Nutanix Objects Storage provides the API-driven storage required for these backend vector stores, as well as the landing zones and model registries used in AI deployments.
- File (RWX) for the CI/CD Pipeline: When multiple pods across different worker nodes need concurrent access to the same directory (like AI training scratch space or shared web assets), Nutanix Files Storage delivers robust ReadWriteMany capabilities.
Note that Nutanix provides a standard CSI driver for provisioning both file and block persistent volumes, and a standard COSI (Container Object Storage Interface) driver for provisioning buckets and access keys.
The Magic of the Unified, App-Centric Snapshot
If a developer asks to protect or clone a production database, standard CSI falls flat. CSI does have the ability to snapshot a volume, but it can't capture the Kubernetes configurations, nor can it snapshot file and block storage types together. With NUS acting as the backend engine, NDK introduces true app-centric data protection. A single NDK snapshot encompasses everything: the block volumes, the file shared data, and all the Kubernetes metadata (manifests, Custom Resources, Secrets, and ConfigMaps) that define the application's state. These snapshots can be asynchronously replicated, typically on a schedule, to another site at which point your cloud-native apps are protected against complete site failure.
When it’s time to recover (or clone if performing a DR test), NDK completely automates the process. It translates the metadata, mounts the NUS storage on the secondary cluster, and automatically reconnects the application to its data copies. It eliminates all the complexity and manual YAML hacking that typically plagues Kubernetes recovery.
Beyond disaster recovery, this deep integration unlocks seamless application rebalancing. An entire application, along with its underlying RWO and RWX data, can be gracefully flipped to another site with a single click. This makes datacenter migrations, load balancing, and planned hardware maintenance completely frictionless. The data moves in a coordinated fashion at the storage layer, and NDK orchestrates the Kubernetes pods to follow it.
Zero-RPO and Seamless Application Rebalancing
With last year’s release of NDK 2.1, Nutanix elevated Kubernetes disaster recovery to even greater heights. Because NDK leverages the battle-tested replication engines of NUS, it also now offers synchronous replication (RPO=0) for both block (RWO) and file (RWX) volumes
Achieving true zero data loss natively within Kubernetes has historically been incredibly difficult. Organizations were typically forced to either accept asynchronous lag (losing valuable minutes of data during an outage) or rely on rigid, complex infrastructure to handle synchronization completely outside of Kubernetes' awareness. NDK bridges this gap seamlessly. By utilizing the mature Metro-level replication capabilities of NUS, the writes made by a containerized application, whether it’s an update to a mission-critical database (Block) or a shared configuration file in a web cluster (File), are simultaneously committed to both the primary and the disaster recovery site.
In the event of an unplanned total site failure, the data on the secondary cluster is perfectly up to date. NDK simply mounts the replicated storage and spins up the Kubernetes pods. The design objective is for an exceptionally fast Recovery Time Objective (RTO) with zero data loss. For the most demanding environments, NDK can even be deployed in robust triple datacenter (3-DC) architectures, where synchronous replication protects against local datacenter failures while asynchronous replication simultaneously secures the data against regional disasters.
The Commercial Reality: A Full-Stack Advantage
Building this level of storage resilience usually requires a patchwork of vendors, one license for the Kubernetes distribution, another for the Kubernetes storage overlay, and yet another for the infrastructure. Nutanix eliminates this silo. Organizations can unlock this unified architecture through the NKP Full-Stack (Pro or Ultimate) licensing, ensuring they have premium Kubernetes management capabilities paired natively with the industry's best software-defined storage tools.
So let me leave you with this one compelling truth: you can’t have enterprise-grade Kubernetes without enterprise-grade storage. NDK provides the seamless, app-centric workflows that Kubernetes operators demand, but it is the raw power, flexibility, and resilience of Nutanix Unified Storage that actually keeps the data safe and performant. Together, they form the ultimate foundation for the stateful, cloud-native enterprise.
©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Kubernetes is a registered trademark of The Linux Foundation in the United States and other countries. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s).
