Kubernetes Data & AI
Kubernetes Data & AI: One Platform Model, Different Infrastructure
Kubernetes was long seen as the layer applications run on. It has become the layer data and AI workloads run on too.
Last updated: September 2026
A Kubernetes Data & AI platform is a platform approach in which data and AI workloads run on a container-based orchestration layer. The lakehouse, query engine, data processing, orchestration, model serving and AI applications are all operated through the same orchestration model, on-premise, in a private cloud and in a public cloud. In this architecture Kubernetes is not merely where applications run; it is the platform's contract for installation, scaling, upgrades and observability.
An enterprise Data & AI platform is not one service. The lakehouse, catalog, query engine, data processing, orchestration, governance, monitoring and AI services all work together, and every one of them has to be installed, versioned, scaled and watched.
That is why Kubernetes ended up underneath data platforms: the same installation and operating model can be repeated across different infrastructure.
The core Kauzas architecture runs on Kubernetes. The same platform model holds on AWS, on VMware and on physical on-premise infrastructure.
What is a Kubernetes Data & AI platform?
A Kubernetes Data & AI platform is a platform model in which an organization runs its data and AI workloads on a container-based orchestration layer. The lakehouse, catalog, query engine, data processing, orchestration and AI services are not server software installed one at a time, but components under the same installation and operating contract.
In practice that means one platform installed, scaled, upgraded and observed the same way on-premise, in a private cloud and in a public cloud. What changes is the infrastructure, not the platform's operating model.
From an application layer to a platform layer
When Kubernetes first spread it was mostly used for stateless applications, and data workloads were long thought unsuited to that model.
What changed this was less Kubernetes itself than the operator ecosystem that grew around it. An operator makes a technology's installation, configuration, scaling and upgrades describable in Kubernetes' own objects.
A data platform's components stop being server software installed one at a time, and become parts of a platform that can be described and reproduced.
What data and AI workloads ask for
Data and AI workloads differ in several ways from the web applications Kubernetes first targeted. To carry them, a platform has to meet:
- Durable state: catalog, metadata and hot-tier data cannot live and die with a pod
- Spiky demand: a Spark job wants dozens of nodes for minutes and then none
- Long-running work: batch jobs may run for hours and cannot take a restart
- Data locality: how close query engines sit to object storage decides performance
- Special hardware: resources such as GPUs have to be visible to the scheduler
- Multi-tenancy: one team's workload must not eat another's capacity
Kubernetes solves none of these by nature. The platform's job is to present a Kubernetes configured to meet them.
The operator model
The components in the Kauzas product catalogue are brought up this way. When an administrator installs a component from the console, that component's operator runs behind it; installation, dependencies and runtime relationships are managed by the platform.
The technologies beneath the Kauzas components are examples of the approach:
| Kauzas component | Underlying technology | Workload type |
|---|---|---|
| Kauzas Spark | Spark on Kubernetes | Batch processing |
| Kauzas Hot Tier | ClickHouse · Altinity Operator | Durable state |
| Kauzas SQL | Trino | Distributed query |
| Kauzas Orchestration | Apache Airflow | Scheduled workflows |
| Kauzas Events | Argo Events + NATS | Event triggering |
| Kauzas Monitoring | Prometheus + Grafana | Observability |
Each component can be versioned independently and taken out of service on its own.
Kubernetes does not make everything portable
It would not be true to say a Kubernetes-based platform runs on any infrastructure without change. What is portable is the platform model; some things stay tied to the infrastructure.
These layers are reconsidered whenever the environment changes:
Storage
The CSI driver providing persistent volumes differs on every infrastructure. On the object storage side the S3 API offers a shared interface, but performance characteristics, consistency behaviour and endpoint configuration vary by provider.
Networking
The choice of CNI, how load balancers are provisioned and the ingress architecture all depend on the infrastructure. In a disconnected network, DNS, certificates and the registry path are designed separately as well.
GPUs
Driver installation, the device plugin and node types differ per environment. In the cloud, GPU node types and quotas decide it; on-premise, the physical card inventory does.
Identity and authorization
How workloads authenticate to storage and other services differs between cloud and on-premise. In Kauzas, user identity is carried through OIDC federation, but access to infrastructure services sits on the environment's own identity model.
Managed services
Meeting a component with a managed cloud service reduces operational load and increases dependence on that environment. It should be a deliberate trade.
Kubernetes does not remove dependencies; it makes them visible and manageable.
The same architecture, different scaling models
The platform's operating model does not change with the infrastructure. What changes is how capacity is provided.
| Infrastructure | Scaling | How it works |
|---|---|---|
| AWS | Karpenter | Nodes come up as needed and capacity is reduced when unused |
| VMware | Cluster API (CAPV) | Virtual machines are brought up as Kubernetes nodes |
| Physical infrastructure | Existing server pool | Workloads scale at the pod level as needed |
The three are as much complements as alternatives. The organization picks its environment against what it needs; the platform's installation, authorization and operating model stays the same.
Where the control plane runs
On a Kubernetes-based platform, where the workloads run is one decision and where the layer that manages them runs is another. Kauzas offers three models:
| Model | Control plane | Data plane |
|---|---|---|
| Fully in-house | Yours | Yours |
| Managed control plane | Novadsa / Kauzas | Yours |
| Central management, distributed sites | Central corporate infrastructure | At your sites |
In all three, data and workloads stay on the organization's own infrastructure. What changes is who operates the management layer.
Kubernetes in a disconnected network
Running a Kubernetes-based platform without internet access takes additional design. Container images have to be served from a registry inside the organization, the certificate chain has to be managed internally, and no component may depend on an external service.
The Kauzas platform is designed to be installed and operated in disconnected networks, and requires no dependency on external services.
Kubernetes and the data lakehouse
A lakehouse separates storage from compute. Kubernetes is what that separation looks like on the compute side: the Iceberg tables on object storage stay where they are, while the Trino and Spark workloads that use them come up as needed and disappear when the work is done.
Separating the query engine's lifetime from the data's lifetime is what an open architecture looks like in operations.
Kubernetes and AI workloads
AI workloads carry a different resource profile from data workloads. Model serving is continuous and latency-sensitive; training and batch inference are spiky and want GPUs.
The practical benefit of running them on the same orchestration layer is that the AI sits next to the data it uses: RAG and agent workloads can reach the enterprise data layer without that data being moved to another platform.
Multi-tenancy and resource management
Different teams use the same platform inside one organization, and a large Spark job run by one team must not slow another team's queries.
Kubernetes namespaces, resource quotas and scheduling provide the foundation for that. In Kauzas it is not only the workload that is carried through but the user's identity and policy context with it; policy-based authorization is applied through Cedar.
That is what makes per-person monitoring and audit possible. How user permissions and agent permissions differ is a separate matter.
The Kauzas approach to Kubernetes
Kauzas treats Kubernetes not as a problem the organization has to solve, but as a contract beneath the platform. An administrator brings components up from the console; installation, dependencies, versioning and integrations are managed by the platform.
- Infrastructure: AWS · VMware · physical
- Kubernetes
- Kauzas core: console, API, authorization, operator
- Data services: catalog · Trino · Spark · hot tier
- AI services: search · agents · model endpoints
- Enterprise applications
Organizations can therefore keep the flexibility of open technologies without building Kubernetes expertise separately for every component.
Who a Kubernetes-based platform suits
The approach is worth weighing particularly for organizations that:
- Run on more than one infrastructure, or may change environment later
- Want data and AI workloads operated on the same platform
- Have disconnected-network or data residency requirements
- Open the same platform to several teams
- Want their existing Kubernetes investment to serve the data platform too
- Prefer not to depend on one cloud provider's managed data services
Frequently asked questions
- What is a Kubernetes Data & AI platform?
- It is a platform approach in which data and AI workloads run on a container-based orchestration layer. Lakehouse, query, processing, orchestration and AI services run under the same installation and operating model across different infrastructure.
- Is Kubernetes suitable for data workloads?
- When configured for them, yes. Durable state, spiky demand and long-running jobs are not things Kubernetes solves by nature; operators, persistent storage drivers and resource management are what meet them.
- Does using Kubernetes make a platform cloud-agnostic?
- Not quite. The platform model becomes portable, but storage drivers, network architecture, how GPUs are provided, the identity model and managed-service dependencies still vary by infrastructure. Kubernetes does not remove those dependencies; it makes them visible.
- Which infrastructure does Kauzas run on?
- It runs on AWS, VMware and physical on-premise infrastructure with the same Kubernetes architecture. Scaling comes from Karpenter on AWS, Cluster API on VMware and the existing server pool on physical infrastructure.
- Can a Kubernetes-based platform run in a disconnected network?
- It can. Container images have to be served from an internal registry and no component may depend on external services. Kauzas can be installed and operated this way.
- Can we use our existing Kubernetes infrastructure?
- Where an organization already has a Kubernetes investment, the platform can sit on top of it. Whether the storage, network and identity layers meet the platform's requirements is assessed before installation.
- How do AI workloads that need GPUs run?
- GPU resources are visible to the Kubernetes scheduler and allocated to workloads. Driver installation and node types differ by infrastructure.
Build Your Platform Independently of the Infrastructure
Where your data and AI infrastructure will run does not have to be a decision made today. The Kauzas Data Platform and the Kauzas AI Platform run on the same Kubernetes architecture on-premise, in a private cloud and in suitable public cloud environments. Let's test Kauzas on your own infrastructure together, in a free PoC.