Every release is built in the XaasIO DevSecOps pipeline and delivered as signed packages and images with an upstream and XaasIO SBOM, license and vulnerability review, and SPDX or CycloneDX outputs.
XaasIO Kubernetes Platform · Managed Kubernetes
Conformant Upstream Kubernetes, Packaged and Automated for Private Cloud
A CNCF-conformant Kubernetes distribution provisioned by Juju, Kubespray or RKE2, one provisioner per deployment, and packaged with validated storage, networking, load balancing, identity, security and observability. On XaasIO Compute, XaasIO Virtualization, XaasIO HCI or bare metal. With XaasIO lifecycle support and production SRE.
XaasIO Kubernetes Platform takes the cluster automation that Juju, Kubespray and RKE2 each provide, high-availability control planes, rolling upgrades, node scaling and air-gapped installs, and packages it with everything a production cluster needs around it: Ceph storage through CSI, Open vSwitch overlays and HAProxy load balancing from XaasIO NFV, single sign-on through XaasIO IAM, CIS-benchmarked hardening and XaasIO MLT telemetry, pinned and signed per release. Virtual machines and containers run on one platform, under one identity and one lifecycle.
Open source by default: Kubernetes, containerd, etcd, Juju, Kubespray, RKE2, Calico, Cilium, Multus, Ceph CSI, MetalLB, HAProxy, Helm and Argo CD, delivered as signed packages and images with an SBOM per release. Customer-operated, co-managed or fully managed by XaasIO. Runs in your data center, sovereign cloud, provider region or air-gapped site.
CNCF-conformant distribution
Pure upstream, production-grade Kubernetes, configured for the estate
The same Kubernetes your teams already know, with no forked API server, scheduler or kubelet. XaasIO adds the configuration, the validated add-ons and the operations around it, and keeps every version pinned per release.
Conformant and Upstream-Aligned
Each release passes the CNCF conformance test suite for its Kubernetes version. The API server, scheduler, controller manager and kubelet are upstream builds, so kubectl, Helm charts and operators behave exactly as documented.
Upstream Kubernetes · CNCF conformance tests per release · Supported minor versions documented in the release policy
High Availability by Default
Three or five control-plane nodes with replicated etcd, an API endpoint behind a floating virtual IP or load balancer, and control-plane and worker placement spread across hosts and racks with anti-affinity rules.
Replicated etcd · API VIP with keepalived or HAProxy · Anti-affinity across hosts and racks · Etcd snapshots on schedule
OCI Runtimes and Your Registry
containerd as the container runtime, CRI-O where a policy requires it, and images pulled from your private OCI registry with signature verification, so nothing in production depends on a public registry being reachable.
containerd · CRI-O option · Private OCI registry with mirroring · Image signing and verification
Workload Isolation
Namespaces, resource quotas, network policies and Pod Security Standards per team; dedicated clusters where a tenant or a regulation requires a hard boundary; and Kata Containers for pods that need their own virtual machine.
Namespaces and quotas · Network policies · Pod Security Standards · Dedicated clusters per tenant · Kata Containers option
GPU, FPGA and SR-IOV Passthrough
Accelerators and network interfaces passed through to nodes on XaasIO Compute or attached directly on bare metal, with device plugins, node feature discovery, NUMA alignment and CPU pinning for AI, HPC and telco workloads.
GPU and FPGA passthrough · SR-IOV and DPDK · Device plugins and node feature discovery · NUMA and CPU pinning
Platform packaging
How the XaasIO Kubernetes Platform is packaged
A Kubernetes distribution is more than the control plane. XaasIO packages the provisioner, the cluster management and observability tools, the validated add-ons for storage, networking, load balancing, identity and security, and the host platform underneath as one tested whole, and ships it with one release cycle and one SBOM.
The map below shows what is in the box. The provisioning band at the top is one of Juju, Kubespray or RKE2, never more than one in a deployment. The column on the left is how the platform is managed and observed. The tiers around the Kubernetes core are the add-ons every cluster gets. The band at the bottom is where the clusters run.
Every item is pinned, packaged, signed and listed in the release SBOM. Items marked optional are installed on request; everything else is part of every cluster. The provisioner, the CNI default and the ingress controller are settled in the assessment.
Provisioning and lifecycle
One cluster, one provisioner: Juju, Kubespray or RKE2
Provisioning is where Kubernetes distributions differ most, and where the operating model is decided. XaasIO validates three upstream provisioners and uses exactly one in any deployment: Juju for model-driven operations, Kubespray for Ansible-driven clusters, RKE2 for hardened clusters that must pass the CIS Benchmark out of the box. The assessment picks one for the estate, from the substrate, the compliance requirements and the tooling the team already runs.
Everything above the provisioner is the same whichever one is chosen: the same CSI and CNI add-ons, the same load balancer and ingress, the same identity, policy, telemetry, registry and GitOps delivery, and the same release cycle. Switching provisioner later means a new cluster and a workload migration, not a different platform, which is why the choice is made once, in the assessment, and documented.
Model-driven clusters with Juju and the Kubernetes charms
Juju is an open-source orchestration engine that deploys and operates applications through charms, with integrations between them as a first-class primitive. XaasIO bootstraps a Juju controller on XaasIO Compute or on MAAS-managed bare metal, deploys the Charmed Kubernetes bundle from a model, and operates the cluster through that model for its whole life.
Chosen when the estate wants model-driven operations across the cluster and the applications on it, runs on OpenStack or MAAS, or already operates other charmed software such as Kubeflow.
Technical foundation: Juju controller and models · Charmed Kubernetes bundle · OpenStack integrator for XaasIO Compute · MAAS for bare metal
Method
A Juju model describes the cluster; the controller provisions machines on the cloud it was bootstrapped against and deploys the charms with their relations. Scaling is a unit count, upgrades are a charm channel change, both applied by the controller.
Cluster components
The Charmed Kubernetes bundle: kubernetes-control-plane, kubernetes-worker, etcd, EasyRSA for certificates, containerd, Calico and the kubeapi-load-balancer, with overlays for the CNI and the cloud integration.
Substrates
XaasIO Compute as an OpenStack cloud, with the OpenStack integrator for Cinder volumes and LoadBalancer services; MAAS-managed bare metal; LXD for development clusters.
Networking defaults
Calico by default; Cilium, Canal, Flannel and Kube-OVN as overlays. Node networks on Open vSwitch overlays from XaasIO NFV.
Day-2 operations
Add or remove units, upgrade through charm channels one application at a time, export the model as a bundle for reproducible rebuilds; one controller operates many models and clusters.
Air gap
Offline charm and snap mirrors and a private image registry inside the boundary, with the controller self-hosted.
License
Juju under the GNU Affero General Public License v3; the charms under their own open-source licenses, listed in the release SBOM.
One deployment, one provisioner. The cluster add-ons, identity, telemetry, registry, delivery pipeline and release cycle are identical across the three, so the choice changes how clusters are built and upgraded, not what runs on them.
Ansible-driven clusters with Kubespray
Kubespray is the Kubernetes SIGs project that deploys production clusters with Ansible. XaasIO keeps one inventory per cluster in Git and runs the playbooks from the XaasIO Unified Automation Platform on Ansible AWX, so every cluster build, scale and upgrade is a logged job with an approval trail.
Chosen when the team already runs Ansible, the estate mixes bare metal and XaasIO Compute, the host operating system is a hard constraint, or clusters are rebuilt often from code.
Technical foundation: Kubespray playbooks and collection · Ansible AWX in the XaasIO Unified Automation Platform · Inventories in Git · OpenStack cloud provider and Cinder CSI
Method
Ansible playbooks: cluster.yml builds the cluster from an inventory, scale.yml adds nodes, upgrade-cluster.yml moves it to a new Kubernetes version in a rolling fashion; node replacement and control-plane recovery are documented procedures.
Cluster components
Upstream Kubernetes binaries, replicated etcd, containerd or CRI-O, CoreDNS, Helm, cert-manager; add-ons for MetalLB, Argo CD, the OpenStack cloud provider, Cinder CSI, local path provisioning and node feature discovery.
Substrates
Bare metal and XaasIO Compute first; XaasIO Virtualization and HCI virtual machines; public cloud instances where a cluster must live there. Supported host distributions include Debian, Ubuntu, Rocky Linux, AlmaLinux, RHEL and Flatcar.
Networking defaults
Calico by default; Cilium, Flannel, Kube-OVN, Kube-Router and Multus as options, with custom CNI supported. Node networks on Open vSwitch overlays from XaasIO NFV.
Day-2 operations
Every change is a playbook run from AWX with the inventory under version control: add, replace or remove nodes, rotate certificates, upgrade one minor version at a time, recover a control plane.
Air gap
Documented offline installation with a local file mirror for binaries and a private registry for images; XaasIO ships both as signed bundles.
License
Apache License 2.0, maintained under the Kubernetes SIGs organization.
One deployment, one provisioner. The cluster add-ons, identity, telemetry, registry, delivery pipeline and release cycle are identical across the three, so the choice changes how clusters are built and upgraded, not what runs on them.
Hardened clusters with RKE2
RKE2, also called RKE Government, is Rancher’s next-generation Kubernetes distribution, built for environments with elevated security and compliance requirements. It installs as a single binary per node, runs the control plane as static pods on an embedded containerd with embedded etcd, and ships defaults that let a cluster pass the CIS Kubernetes Benchmark with minimal operator intervention. XaasIO uses RKE2 standalone, with Rancher Manager as an option.
Chosen when the estate is regulated or governmental, clusters must pass the CIS Benchmark or need FIPS 140-2 builds, or the site is air-gapped and wants the simplest offline install and upgrade path. RKE1 reached end of life on July 31, 2025; XaasIO does not deploy it.
Technical foundation: rke2-server and rke2-agent · Embedded containerd and etcd · CIS profiles · system-upgrade-controller · Rancher Manager (optional)
Method
A configuration file and one binary per node: rke2-server on control-plane nodes, rke2-agent on workers. Nodes join with a token; the control plane runs as static pods managed by the kubelet. Provisioning of the nodes themselves comes from XaasIO Compute, Virtualization or bare metal.
Cluster components
Upstream Kubernetes with embedded etcd and containerd, CoreDNS, metrics server, the bundled CNI, a Helm controller for add-ons, and components scanned with Trivy in the build pipeline; FIPS 140-2 compliant builds available.
Substrates
Bare metal, XaasIO Virtualization and HCI, and XaasIO Compute with the OpenStack cloud controller manager and Cinder CSI installed as add-ons.
Networking defaults
Canal by default; Calico, Cilium and Flannel bundled; Multus as a secondary CNI; dual-stack IPv4 and IPv6 at cluster creation. Node networks on Open vSwitch overlays from XaasIO NFV.
Day-2 operations
Upgrades by replacing the binary or automated with the system-upgrade-controller, node by node; etcd snapshots on schedule with restore procedures; CIS profile enforced through the configuration file.
Air gap
Image tarballs placed on each node, a private registry with the system-default-registry setting, Hauler bundles or the embedded registry mirror; offline upgrades follow the same paths.
License
Apache License 2.0.
One deployment, one provisioner. The cluster add-ons, identity, telemetry, registry, delivery pipeline and release cycle are identical across the three, so the choice changes how clusters are built and upgraded, not what runs on them.
Which provisioner for which estate
Juju, Kubespray or RKE2, compared
| Dimension | Juju | Kubespray | RKE2 |
|---|---|---|---|
| Method | Model-driven: a Juju controller provisions machines and deploys the Charmed Kubernetes charms with their relations | Ansible playbooks (cluster.yml, scale.yml, upgrade-cluster.yml) from an inventory in Git, run from Ansible AWX | One binary per node (rke2-server, rke2-agent) with a configuration file; control plane as static pods, embedded etcd and containerd |
| Substrates | XaasIO Compute as an OpenStack cloud, MAAS-managed bare metal, LXD for development | Bare metal, XaasIO Compute, XaasIO Virtualization and HCI, public cloud instances | Bare metal, XaasIO Virtualization and HCI, XaasIO Compute with the OpenStack cloud controller manager |
| Default CNI | Calico; Cilium, Canal, Flannel and Kube-OVN as overlays | Calico; Cilium, Flannel, Kube-OVN, Kube-Router, Multus and custom CNI | Canal; Calico, Cilium and Flannel bundled; Multus as secondary CNI |
| Container runtime | containerd (charm) | containerd or CRI-O | Embedded containerd |
| Control-plane HA | Several control-plane units, an etcd cluster and the kubeapi-load-balancer | Several control planes with replicated etcd behind an API VIP or load balancer | Several servers with embedded etcd behind a fixed registration address or VIP |
| Upgrades | Charm channel change per application, applied by the controller | upgrade-cluster.yml, rolling, one minor version at a time | Binary replacement node by node, or automated with the system-upgrade-controller |
| Air gap | Offline charm and snap mirrors with a private image registry | Documented offline install with a local file mirror and a private registry | Image tarballs on each node, a private registry, Hauler bundles or the embedded registry mirror |
| Compliance posture | Hardening applied by the XaasIO cluster standard | Hardening applied by the XaasIO cluster standard and playbook options | CIS Benchmark profile built in, FIPS 140-2 builds, components scanned with Trivy |
| Strongest fit | Model-driven operations across clusters and the applications on them, on OpenStack or MAAS | Ansible-centric teams, mixed bare metal and OpenStack estates, strict host operating system requirements | Regulated and government estates, CIS and FIPS requirements, air-gapped sites |
| License | GNU AGPL v3 for Juju; charms under their own open-source licenses | Apache License 2.0, under the Kubernetes SIGs organization | Apache License 2.0, from Rancher by SUSE |
Defaults are the upstream defaults XaasIO validates; the assessment may select another option from the same list. Whichever provisioner is chosen, the add-ons above it come from the same XaasIO release.
Where the clusters run
Kubernetes on XaasIO Compute, on bare metal, on XaasIO Virtualization
Most estates run containers and virtual machines side by side for years. XaasIO Kubernetes Platform runs on the same XaasIO host platforms as the virtual machines, with the same storage, the same overlay network, the same identity and the same operations team, so there is no second platform to buy and no second operating model to learn.
On XaasIO Compute the clusters are OpenStack tenants with self-service, quotas and the cloud provider integrations. On bare metal they get the whole server for AI, HPC and telco workloads. On XaasIO Virtualization and HCI they live beside the virtual machines of a VMware exit. The provisioner is the same choice in all three.
Private cloud · XaasIO Compute on OpenStack
Kubernetes on XaasIO Compute
- One platform for containers and virtual machines: clusters are OpenStack projects with quotas, self-service through the XaasIO Hyperscaler Console and tenant isolation on Neutron networks and security groups
- Nodes as Nova instances with server groups and anti-affinity, flavors for control plane, general workers and GPU workers, and Ironic for bare-metal nodes inside the same project
- The OpenStack cloud provider for node lifecycle, Cinder CSI for Ceph-backed block volumes and Manila CSI for shared file systems, with volume snapshots and encryption
- LoadBalancer services from the XaasIO NFV HAProxy service, compatible with the OpenStack load balancer API, and floating IPs from the provider edge; SR-IOV, DPDK and Open vSwitch offload where throughput matters
- One support contract for OpenStack, Ceph, the overlay and Kubernetes, and one XaasIO MLT view across all of them
Bare metal and virtualization · Ironic, MAAS and KVM
Kubernetes on bare metal and XaasIO Virtualization
- Bare-metal performance for AI training, HPC, databases and packet-processing workloads: no hypervisor in the path, GPUs and NICs attached directly, NUMA-aware scheduling
- Servers provisioned by OpenStack Ironic or MAAS with the XaasIO validated host image, inventoried and re-imaged from the catalog; GPU auto-detection with node feature discovery
- On XaasIO Virtualization and HCI, nodes as KVM virtual machines beside the migrated workloads of a VMware exit, with the same Ceph pools and Open vSwitch networks
- Ceph RBD and CephFS through the Ceph CSI driver and S3 object storage from the same cluster; MetalLB or the XaasIO NFV HAProxy pair for LoadBalancer services
- Full-stack high availability: control plane spread across hosts and racks, Ceph replicated or erasure-coded across failure domains, host failure handled by the platform
Public cloud is not excluded: where a cluster must run in AWS, Azure or Google Cloud, it is provisioned there with the same provisioner and the same add-ons and managed from the same XaasIO CMP, with the differences in storage and load balancing documented per cloud.
Built for the workloads a private cloud runs
The cluster underneath the other XaasIO platforms
AI, Machine Learning and HPC
GPU node pools with the NVIDIA GPU Operator and device plugins, Kubeflow pipelines and notebooks, KServe and vLLM for inference, and Slurm-on-Kubernetes or dedicated HPC partitions: the cluster layer of the XaasIO AI Factory and AI Token Factory.
Data Platforms
Kafka, OpenSearch, Spark, Trino and Flink as operators on dedicated node pools with Ceph S3 and CephFS underneath, with the XaasIO AI Lake S3 Edition running its processing and serving layers here.
Managed Databases
PostgreSQL, MySQL and MongoDB clusters operated by OpenEverest on Ceph block storage with backups to S3: XaasIO RDS runs on XaasIO Kubernetes, in the same clusters or dedicated ones.
Telco and Network Functions
SR-IOV, DPDK, Multus multi-network pods, NUMA and CPU pinning, real-time kernels and validated cloud-native network functions, with the overlay, edge and load balancer from XaasIO NFV.
Edge, Sovereign and Air-Gapped
Small conformant clusters on two or three nodes at the edge, full clusters in sovereign regions, and air-gapped sites with mirrored registries and signed offline bundles, all operated from the same tooling.
Platform Engineering and Tanzu Exit
GitOps delivery with Argo CD through the XaasIO Unified Automation Platform, namespaces and clusters as catalog items, and the landing zone for workloads leaving VMware Tanzu or being containerized during a VMware migration.
What is in every cluster
Every layer validated, from the host image to the ingress
| Layer | XaasIO Kubernetes component | Plays the role of | Delivered as |
|---|---|---|---|
| Cluster provisioning and lifecycle | Juju, Kubespray or RKE2, one per deployment | Tanzu Kubernetes Grid, the OpenShift installer, cloud-managed control planes | A cluster standard per estate; clusters ordered from XaasIO CMP or the Hyperscaler Console |
| Kubernetes core | Upstream Kubernetes, etcd, CoreDNS | The control plane of any distribution | Conformance-tested per release; supported versions listed in the release policy |
| Container runtime | containerd; CRI-O as an option | Docker-era runtimes | Pinned per release with the host image |
| Host platform and image | XaasIO validated host image on XaasIO Compute, Virtualization, HCI or bare metal | The node operating systems of Tanzu and OpenShift | Signed image with SBOM, patched and upgraded on the release cycle |
| Pod networking (CNI) | Calico, Cilium or Canal; Multus for multi-network pods; SR-IOV and DPDK | Antrea, the NSX container plugin, OpenShift SDN and OVN-Kubernetes | Default per provisioner; selected and documented in the assessment |
| Node networking, overlay and edge | XaasIO NFV: Open vSwitch VXLAN overlays, security groups, OPNsense edges | NSX | Part of the host platform |
| Storage (CSI) | Ceph RBD and CephFS CSI; Cinder and Manila CSI on XaasIO Compute; Ceph S3 object storage | vSAN and the vSphere CSI driver, OpenShift Data Foundation | From XaasIO Block and Object Storage; snapshots and Velero backups to S3 |
| Load balancing and ingress | MetalLB or the XaasIO NFV HAProxy service; Gateway API with Traefik or the HAProxy ingress controller; Istio as an option | NSX Advanced Load Balancer, the OpenShift router, cloud load balancers | Installed with every cluster; Ingress NGINX is not shipped, as the upstream project retired it in March 2026 |
| Identity and access | XaasIO IAM with OIDC and SAML, LDAP and Active Directory, Kubernetes RBAC, Open Policy Agent, audit logging | OpenShift OAuth, Tanzu Mission Control, cloud IAM | Single sign-on for every cluster; roles mapped from directory groups |
| Security and compliance | CIS Benchmark profiles, kube-bench, Trivy, OpenSCAP, AppArmor and SELinux, Pod Security Standards, cert-manager, OpenBao secrets, image signing | Container security platforms, the OpenShift Compliance Operator | Hardening applied by the cluster standard; evidence package in the Hardening and Compliance Pack |
| Registry and delivery | Private OCI registry with mirroring, Helm, Argo CD through the XaasIO Unified Automation Platform | Harbor on Tanzu, OpenShift GitOps and the OpenShift image registry | Per estate, inside the boundary for air-gapped sites |
| Observability | XaasIO MLT: Prometheus, Alertmanager, Grafana, OpenSearch, OpenTelemetry | Tanzu Observability, OpenShift monitoring and logging | Agents installed with every cluster; dashboards and alerts per cluster and team |
| Validated applications | Kubeflow, KServe, vLLM, OpenEverest, Kafka, OpenSearch, Trino, Spark, Flink | Marketplace and OperatorHub catalogs | Catalog items from XaasIO AI Factory, AI Lake and RDS |
| Backup and recovery | Etcd snapshots, Velero to Ceph S3, the XaasIO DR and Replication Platform for site recovery | Velero on Tanzu, OADP on OpenShift | Scheduled per cluster; restore drills in the Upgrade and Lifecycle Pack |
“Plays the role of” names the product category a layer stands in for in a typical Tanzu, OpenShift or cloud-managed estate. It is a category mapping, not a feature-for-feature claim; the assessment maps the features you use and marks what is partial.
HOW IT WORKS
One request. From cluster definition to delivered, observed service.
01
Assess
The assessment settles the provisioner, the substrate, the CNI and ingress defaults, cluster boundaries per team or tenant, and the compliance profile, and records them as the cluster standard.
02
Provision
A platform team or a tenant orders a cluster from the XaasIO CMP catalog or the Hyperscaler Console. Juju, Kubespray or RKE2 builds it from the standard: control plane, etcd, workers, runtime and CNI.
03
Integrate
The add-ons join automatically: Ceph or Cinder CSI, the load balancer and ingress, XaasIO IAM single sign-on, policies and hardening, the private registry and XaasIO MLT agents.
04
Deliver
Applications arrive through Helm and Argo CD from Git, with namespaces, quotas, network policies and secrets provisioned per team; validated applications come from the catalog.
05
Operate
Metrics, logs and traces flow into XaasIO MLT; upgrades, certificate rotation and node replacement run as jobs from XaasIO CMP on the release cycle, rehearsed in a pilot cluster first.
Teams request clusters and namespaces. XaasIO Kubernetes Platform owns the provisioner, the add-ons, the policy, the upgrades and the audit trail. The host platform owns the servers, the storage and the network underneath.
Works with the XaasIO platforms
The container layer of every XaasIO private cloud
XaasIO Kubernetes Platform consumes storage from XaasIO Block and Object Storage, networking and load balancing from XaasIO NFV, identity from XaasIO IAM, and telemetry from XaasIO MLT, and it is the cluster underneath XaasIO RDS, AI Factory and AI Lake. XaasIO CMP and the XaasIO Hyperscaler Platform publish clusters and namespaces as governed, metered services.
Clusters as OpenStack projects on XaasIO Compute
KVM node pools on XaasIO Virtualization and HCI
Ceph RBD, CephFS and S3 through CSI
Overlays, HAProxy load balancing and edges from XaasIO NFV
Clusters and namespaces as catalog items in XaasIO CMP
Metrics, logs and traces in XaasIO MLT
XaasIO Compute
Clusters as OpenStack projects: Nova and Ironic nodes, Neutron networks and security groups, Cinder and Manila CSI, the cloud provider and the load balancer service, with quotas and self-service per tenant.
XaasIO Virtualization and HCI
KVM node pools beside the virtual machines of a VMware exit, Ceph CSI from the HCI storage pools, Open vSwitch networks and MetalLB or HAProxy pairs: the Tanzu path of the VMware migration.
XaasIO Storage and NFV
Ceph block, file and object storage through CSI with snapshots and Velero backups; VXLAN overlays, security groups, OPNsense edges and HAProxy LoadBalancer services and ingress for every cluster.
XaasIO CMP, MLT and Hyperscaler Platform
Clusters, node pools and namespaces as catalog items with approvals and Ansible Day-2 runbooks; dashboards and alerts per cluster and team; usage metered and billed for service providers.
PLANNING TOOL
Size the clusters
Control-plane nodes, worker nodes, allocatable capacity and pod address space are counted, not guessed. Enter how many clusters you expect, how large each should be and what a worker node looks like, and the planner returns the node counts, the capacity left for workloads after system reservations, the pod capacity and the pod network each cluster needs. Performance and exact flavors come from the assessment, not from this tool.
Cluster planner
Nodes in total 36
Allocatable vCPU 326
Allocatable memory 1,305 GB
Pod capacity 1,440
Pod network per cluster /19
Capacity with one worker down 83%
Planning estimate only. Control-plane nodes are counted but not used for workloads; allocatable capacity reserves 15 percent of each worker for the operating system, kubelet, runtime and the platform add-ons; pod capacity is pods per node times worker nodes; the pod network allows a /24 per node with room to double the node count; the last figure is the share of allocatable worker capacity a cluster keeps when one worker is down. Real sizing follows the assessment and the workload profiles.
DEPLOYMENT MODELS
Choose the design that fits the estate
Private Cloud Kubernetes
Clusters as self-service OpenStack projects on XaasIO Compute, one or more per team, with Cinder and Manila storage, the load balancer service, floating IPs and quotas, ordered from the Hyperscaler Console.
Enterprise Kubernetes beside Virtual Machines
KVM node pools on XaasIO Virtualization and HCI clusters with Ceph CSI and Open vSwitch networks: the landing zone for Tanzu clusters and for workloads containerized during a VMware exit.
Bare-Metal Kubernetes for AI, HPC and Telco
Ironic or MAAS-provisioned servers with GPUs, SR-IOV and DPDK, NUMA-aware scheduling and dedicated node pools, underneath the XaasIO AI Factory or validated network functions.
Multi-Site, Sovereign and Air-Gapped
Clusters per site and region, RKE2 or Kubespray with mirrored registries and signed offline bundles inside the boundary, operator access through NetBird or Netmaker, all control planes self-hosted.
WHAT IS INCLUDED
One platform. The XaasIO platforms around it.
XaasIO Kubernetes Platform is delivered with the XaasIO host platform its nodes run on. Storage and networking come from the host platform's XaasIO Storage and NFV layers, and the other platforms add the catalog, the telemetry and the billing.
XaasIO Kubernetes Platform
Included: the conformant distribution, the chosen provisioner with its cluster standard, the validated add-ons for storage, networking, load balancing, identity, security, registry and GitOps delivery, APIs, Ansible runbooks and the release cycle.
XaasIO Compute, Virtualization, HCI or Bare Metal
Required host platform: where the control-plane and worker nodes run, with XaasIO Storage for Ceph and XaasIO NFV for overlays, edges and load balancing. Any one of them, or a mix under one XaasIO CMP.
XaasIO MLT
Optional, recommended: cluster, node, pod and application metrics, logs and traces with dashboards and alerts per cluster and team, and the AI-native extension where XaasIO AI Lake is present.
XaasIO CMP and Hyperscaler Platform
Optional: clusters and namespaces as governed catalog items with approvals, Day-2 automation and FinOps, and, for service providers, rating, invoicing and payments.
OPERATING MODEL
Kubernetes without the integration burden
XaasIO designs, deploys, validates and supports the Kubernetes platform as one production system rather than a provisioner, a dozen add-ons and a set of scripts held together by one team.
Validated Architecture
Provisioner, host image, control-plane layout, add-ons, identity, policy and telemetry sized and tested as one architecture on the XaasIO host platforms, with the version skew between every component checked per release.
Controlled Lifecycle
Documented release, patching, upgrade, compatibility, rollback and maintenance procedures for Kubernetes, the provisioner and every add-on, with every version pinned per release and upgrades rehearsed in a pilot cluster.
Secure Software Supply Chain
Flexible Operating Model
Customer-operated, co-managed, fully managed, or a dedicated XaasIO SRE Pod with 16x5 or 24x7 coverage.
Advanced Kubernetes Support Packs
Tanzu and OpenShift Exit Pack
Cluster, add-on and workload inventory, mapping to the XaasIO cluster standard with partial items marked, and a wave plan aligned with the VMware migration
Hardening and Compliance Pack
CIS Benchmark profile, Pod Security Standards, FIPS builds where required, OpenSCAP host scans, audit logging and the evidence package for the auditor
GPU and Accelerator Pack
GPU node pools, the NVIDIA GPU Operator, device plugins, NUMA and CPU pinning, MIG and time-slicing profiles, measured on your hardware
ITSM Integration Pack
Mirrored registry and file mirror inside the boundary, signed offline bundles for installs and upgrades, and the runbooks for operating without an internet path
Multi-Cluster GitOps Pack
Argo CD through the XaasIO Unified Automation Platform, cluster and namespace templates, policy as code and promotion between environments
Upgrade and Lifecycle Pack
Upgrade rehearsal per minor version in a pilot cluster, version-skew checks, etcd backup and restore drills, and node replacement runbooks
KEY TERMS
Glossary
Kubernetes terms used on this page.
Conformant Kubernetes
A Kubernetes build that passes the CNCF conformance test suite for its version, so the API behaves as documented and workloads, tooling and operators move between conformant clusters without change.
Control plane and etcd
The API server, scheduler and controller manager that run the cluster, and etcd, the replicated key-value store that holds its state. Three or five control-plane nodes keep both available through node failures.
Provisioner
The tool that turns machines into a cluster and keeps it current: installs the control plane and nodes, joins them, scales them and upgrades them. Juju, Kubespray and RKE2 are the three XaasIO validates.
Charm and model
In Juju, a charm packages the operations code for one application and a model is the description of a deployment: which charms, how many units, and the relations between them. The controller makes the model real.
Inventory and playbook
In Kubespray, the inventory lists the hosts and their roles and the playbooks are the Ansible procedures that build, scale and upgrade the cluster from it. Both live in Git.
CIS Kubernetes Benchmark
A published set of configuration checks for hardening Kubernetes clusters from the Center for Internet Security. RKE2 ships defaults that pass it with minimal intervention; kube-bench verifies any cluster against it.
CNI and CSI
The Container Network Interface and the Container Storage Interface: the plugin standards through which a cluster gets pod networking (Calico, Cilium, Canal) and persistent storage (Ceph, Cinder, Manila).
Overlay network
A virtual network carried in tunnels over the physical fabric. Pod networks are overlays inside the cluster; node networks on XaasIO are VXLAN overlays on Open vSwitch provided by XaasIO NFV.
LoadBalancer service, Ingress and Gateway API
A LoadBalancer service exposes an application on an external IP from MetalLB or the HAProxy service. Ingress and its successor, the Gateway API, route HTTP traffic by host and path through an ingress controller or gateway.
GitOps
Operating clusters and applications from declarations in Git: Argo CD continuously compares the cluster with the repository and applies the difference, so every change is reviewed, versioned and auditable.
Air-gapped cluster
A cluster with no path to the internet. Binaries, charms, images and updates arrive as signed bundles through a controlled transfer and are served from mirrors and a registry inside the boundary.
Pod Security Standards
The Kubernetes policy levels, privileged, baseline and restricted, that limit what a pod may do, enforced per namespace by the built-in admission controller.
Frequently asked questions
What is the XaasIO Kubernetes Platform?
XaasIO Kubernetes Platform is the container platform of the XaasIO private cloud, listed as Managed Kubernetes in the platform menu. It is a CNCF-conformant distribution of upstream Kubernetes, provisioned by Juju, Kubespray or RKE2, and packaged with validated add-ons for storage, networking, load balancing, identity, security, observability, registry and GitOps delivery. XaasIO pins, packages, signs, supports and can operate all of it under one release cycle on XaasIO Compute, XaasIO Virtualization, XaasIO HCI or bare metal.
Is it upstream Kubernetes, and is it conformant?
Yes. The API server, scheduler, controller manager and kubelet are upstream builds of the Kubernetes version each release supports, with no XaasIO fork. Every release passes the CNCF conformance test suite for that version before it ships, so kubectl, Helm charts, operators and the Kubernetes documentation apply as written. The supported minor versions and the upgrade windows are published in the release policy.
Why three provisioners, and why only one per deployment?
Because the provisioner is where estates differ most. Juju suits teams that want model-driven operations across clusters and the applications on them, typically on OpenStack or MAAS. Kubespray suits teams that already run Ansible and estates that mix bare metal with XaasIO Compute, with the broadest choice of host operating systems. RKE2 suits regulated and air-gapped estates that need the CIS Benchmark profile and FIPS builds out of the box. Running more than one in a deployment would double the cluster standard, the runbooks and the upgrade rehearsals, so XaasIO uses exactly one. Everything above the provisioner is the same.
How do you choose between Juju, Kubespray and RKE2?
In the assessment. The inputs are the substrate (XaasIO Compute, Virtualization, HCI, bare metal), the compliance profile (CIS, FIPS, air gap), the tooling the operations team already runs (Ansible, Juju, Rancher), the host operating system constraints and the applications planned for the clusters. The output is a written cluster standard: provisioner, versions, CNI, ingress, storage classes, identity mapping, hardening and the upgrade procedure, which every cluster in the estate follows.
What about RKE1?
RKE, the original Rancher Kubernetes Engine, reached end of life on July 31, 2025, and its Docker-based design has no place in current Kubernetes. XaasIO deploys RKE2, which runs the control plane as static pods on an embedded containerd, and helps clusters still on RKE1 move: there is no in-place conversion, so workloads are redeployed onto new RKE2 clusters in waves, with the Tanzu and OpenShift Exit Pack method applied.
Is this a replacement for VMware Tanzu or Red Hat OpenShift?
For the Kubernetes part, yes: conformant clusters with lifecycle management, storage, networking, load balancing, identity, registry, GitOps delivery and observability all have a component here, and the VMware migration playbook maps Tanzu clusters to the XaasIO Kubernetes Platform. It is not a feature-for-feature replacement for either product: OpenShift's integrated developer console, build system and operator catalog, or Tanzu Mission Control, have equivalents here only in part, and the Tanzu and OpenShift Exit Pack inventories what you use and marks what is partial before any migration starts.
How is storage provided?
From XaasIO Block and Object Storage. On bare metal and XaasIO Virtualization the Ceph CSI driver provides RBD block volumes and CephFS shared file systems with snapshots and expansion; on XaasIO Compute the Cinder CSI driver provides Ceph-backed block volumes with encryption and Manila CSI provides shared file systems through the OpenStack APIs. Object storage comes from Ceph S3, which is also where Velero writes cluster and volume backups. Storage classes are part of the cluster standard, so every cluster gets the same names and the same policies.
How is networking provided?
Two layers. Node networks, security groups, the overlay between hosts, floating IPs and the tenant edge come from XaasIO NFV: VXLAN overlays on Open vSwitch with OPNsense edges. Pod networking comes from the CNI inside the cluster: Calico by default with Juju and Kubespray, Canal by default with RKE2, Cilium validated on all three, Multus where a pod needs more than one interface, and SR-IOV and DPDK for packet-processing workloads. Network policies are enforced by the CNI; the assessment decides whether policy is written per namespace by teams or centrally as code.
How do LoadBalancer services and ingress work?
LoadBalancer services get external IPs from MetalLB on bare metal and XaasIO Virtualization, or from the XaasIO NFV HAProxy service, which is compatible with the OpenStack load balancer API, on XaasIO Compute. HTTP routing uses the Gateway API, with Traefik or the HAProxy Kubernetes ingress controller serving both Gateway API and the Ingress API, and Istio is available where a service mesh is wanted. XaasIO does not ship Ingress NGINX: the upstream project retired it in March 2026 and no longer publishes releases or security fixes, so estates still on it are moved during onboarding.
How is identity and access handled?
Every cluster authenticates through XaasIO IAM with OIDC, with SAML, LDAP and Active Directory behind it, so the same users, groups and single sign-on apply to the Hyperscaler Console, XaasIO CMP and kubectl. Directory groups map to Kubernetes RBAC roles per cluster and namespace, Open Policy Agent enforces admission policies, and audit logs go to XaasIO MLT. Service accounts and workload identity follow the cluster standard, and secrets are stored in OpenBao with the Kubernetes secrets store integration.
How is the platform hardened?
The cluster standard applies the CIS Kubernetes Benchmark profile, Pod Security Standards per namespace, network policies, API audit logging, encrypted etcd, certificate rotation and image signature verification. kube-bench and Trivy run against every cluster, OpenSCAP scans the host image, AppArmor or SELinux confines the nodes, and FIPS 140-2 builds are available with RKE2 where a regulation requires them. The Hardening and Compliance Pack produces the evidence package for the auditor.
Can the platform run in an air-gapped environment?
Yes. Each provisioner has a documented offline path: Juju with offline charm and snap mirrors, Kubespray with a local file mirror, RKE2 with image tarballs, a private registry, Hauler bundles or its embedded registry mirror. XaasIO ships the binaries, images, charts and host images as signed offline bundles on the release cycle, the private registry and the GitOps repositories run inside the boundary, and XaasIO MLT, IAM and the Unified Automation Platform are self-hosted. The Air-Gap Pack covers the transfer procedure and the runbooks.
How are upgrades done?
One minor version at a time, on the release cycle, rehearsed first in a pilot cluster that mirrors the standard. Juju applies a charm channel change per application; Kubespray runs upgrade-cluster.yml as a rolling job from Ansible AWX; RKE2 replaces the binary node by node or automates it with the system-upgrade-controller. Add-ons are upgraded in the same release with their version skew checked, etcd is snapshotted before every step, and the procedure, the rollback and the maintenance window are documented per cluster.
How is multi-tenancy handled: clusters or namespaces?
Both, by policy. Teams that share a trust boundary get namespaces with quotas, network policies, Pod Security Standards and their own RBAC in a shared cluster. Tenants, regulated workloads and workloads with conflicting cluster-level requirements get dedicated clusters, which on XaasIO Compute are separate OpenStack projects. Clusters and namespaces are both catalog items in XaasIO CMP and the Hyperscaler Platform, with usage metered per tenant for service providers.
Are the components open source, and what are the licenses?
Kubernetes, containerd, etcd, Kubespray, RKE2, Calico, Cilium, Multus, MetalLB, Helm, Argo CD, Ceph and the Ceph CSI driver are Apache 2.0 or similarly permissive; Juju is under the GNU Affero General Public License v3, with the charms under their own open-source licenses; HAProxy is GPLv2 with LGPL libraries; Open vSwitch is Apache 2.0. XaasIO lists the exact versions and licenses of every component in the release SBOM, and no proprietary license key is needed to run the platform. Rancher Manager, where it is used, is Apache 2.0 with commercial support from SUSE.
Are other XaasIO platforms required?
XaasIO Kubernetes Platform needs a XaasIO host platform to run on: Compute, Virtualization or HCI, or bare metal provisioned by XaasIO, which brings XaasIO Storage and NFV with it. XaasIO MLT is optional and recommended for observability. XaasIO CMP and the XaasIO Hyperscaler Platform are optional and add the governed catalog, Day-2 automation, metering and billing. XaasIO RDS, AI Factory and AI Lake run on this platform when they are procured.
Who operates the XaasIO Kubernetes Platform?
You choose: customer-operated with XaasIO support, co-managed, fully managed by XaasIO, or a dedicated XaasIO SRE Pod with 16x5 or 24x7 coverage. Every deployment includes a validated architecture, the written cluster standard, a documented release and upgrade policy and an SBOM for every release.
Kubernetes, CNCF, Juju, Charmed Kubernetes, MAAS, LXD, Canonical, Kubespray, RKE2, Rancher, SUSE, VMware, Tanzu, Red Hat, OpenShift, OpenStack, Ceph, Open vSwitch, HAProxy, Calico, Cilium, Flannel, Multus, MetalLB, Traefik, NGINX, Istio, Helm, Argo CD, Harbor, Kubeflow, KServe, vLLM, NVIDIA, Kafka, OpenSearch, Trino, Spark, Flink, Prometheus, Grafana, OpenTelemetry, OpenSCAP, Trivy, OpenBao, Velero, cert-manager, Open Policy Agent, Kata Containers, Ansible, Amazon Web Services, Microsoft Azure, Google Cloud and other product names are trademarks of their respective owners and are named for identification and comparison only. XaasIO is not affiliated with, endorsed by or sponsored by these organizations.
Build what the world depends on.
Planning a cloud for government, financial services, pharmaceuticals, healthcare, energy, transport, industry, service-provider operations, or private AI? Work with XaasIO to define the architecture, security boundary, and operating model your environment requires.