Kubernetes platforms
Kubernetes platforms
Provision and operate self-managed Kubernetes clusters with Magnum on Quake AI. You operate cluster add-ons, ingress, and workload manifests; Quake AI provides the Magnum control plane, compute nodes, networking, and block and object storage.
What this is for#
Platform teams that standardize on Kubernetes need a cluster they control end to end: control plane, worker pool, ingress, storage classes, and add-ons. Quake AI provisions the Magnum cluster and the compute, network, and storage primitives underneath; you operate the workloads, ingress controller, and cluster lifecycle. The outcome is a self-managed Kubernetes platform with flat egress and plan-based node pricing, deployable from a validated OpenTofu template and its companion tutorial.
Reference architecture#
Download diagram: SVG, PNG, and PDF.
The platform is the Kubernetes cluster template plus two value-add variations. Each tier maps to the diagram and to the template or how-to that builds it.
-
Platform users. Developers and end users reach workloads over HTTPS through the cluster's ingress. A Kubernetes
Servicewithtype: LoadBalancercan allocate a public address for supported cluster ingress. You manage ingress certificates through your controller or certificate operator. -
Magnum control plane. Quake AI provisions the Kubernetes control plane (OpenStack Magnum) inside your project. Your team operates control plane availability, upgrades, and certificates.
-
Worker nodes. Workloads run on Compute worker nodes. The Kubernetes cluster template provisions the cluster, worker pool, networking, and storage hooks. Stateful workloads bind PersistentVolumeClaims to Block Storage volumes.
-
Value-add variations. The registry variation adds a self-hosted Harbor registry the cluster pulls images from, and the monitoring variation adds a monitoring stack (Prometheus and Grafana) for control plane and worker health. Container images, Helm archives, and backups can also live in S3-compatible Object Storage.
Services involved#
| Service | Role in this architecture | Docs |
|---|---|---|
| Kubernetes (Magnum) | Self-managed control plane and worker pool | Kubernetes |
| Compute | Worker node instances | Compute |
| Network | Private networks, routers, and security groups for the cluster | Network |
| Cluster ingress | Public service exposure and traffic routing | Kubernetes |
| Self-managed TLS | Certificates for cluster ingress | Let's Encrypt certificates |
| Block Storage | PersistentVolumeClaim backing volumes | Block Storage |
| Object Storage | Container images, Helm archives, and backups | Object Storage |
Get started#
Start from the template, then follow its deploy tutorial to stand up the cluster.
- Kubernetes cluster template and its deploy tutorial: Magnum cluster with worker nodes, networking, and storage hooks for common platform layouts.
- Create a Kubernetes cluster: step-by-step cluster provisioning through the Console or OpenStack CLI.
- Deploy a Helm chart: install packaged workloads on a Magnum cluster.
- OpenTofu template library: browse validated IaC starting points for cluster and platform stacks.
Estimate the cost#
Monthly cost estimate
Pricing calculator ↗Sized as a custom package on a mix of shared and dedicated vCPU.
Monthly total for the required template above. Use the configurator below to add optional pieces and see the total update.
What each resource is for
Control plane
m2a.xlarge · 4 dedicated vCPU, 16 GiB RAM, 1 Gbps
3× Worker node
s1a.medium · 4 shared vCPU, 4 GiB RAM, 0.5 Gbps
Compute shown per role at custom-package rates ($29/dedicated vCPU, $7.25/shared vCPU, $1/GiB RAM). The headline above is the billed total: the cheaper of a named plan and the custom package, plus add-ons.
Included in baseline
m2a.xlarge
4 dedicated vCPU, 16 GiB RAM, 1 Gbps
s1a.medium
4 shared vCPU, 4 GiB RAM, 0.5 Gbps
s1a.medium
4 shared vCPU, 4 GiB RAM, 0.5 Gbps
s1a.medium
4 shared vCPU, 4 GiB RAM, 0.5 Gbps
Compute + RAM rate basis
16 vCPU + 28 GiB RAM at $29/dedicated vCPU, $7.25/shared vCPU, $1/GiB RAM (regular). Totals apply the flat −$5/mo package promotion.
Block storage (160 GiB)
160 GiB at $0.08/GiB/mo
Public IP (included)
1 included with the custom package
Package promotional discount
Flat −$5.00/mo on the custom package (same promotion as named plans).
Included at no charge
These line items are zero on Quake AI. Many other providers meter them separately.
Data transfer (inbound and outbound)
Unlimited data transfer on every plan; Quake AI does not meter per-GB egress.
AWS, GCP, and Azure meter outbound transfer per GB. DigitalOcean and Hetzner include an allowance on compute plans, then charge overage.
Learn morePrivate networking
Private networks, subnets, Neutron routers, and security groups are included with the plan.
VPC objects are usually free to create elsewhere, but NAT gateways bill hourly plus per-GB processed. Quake AI uses router SNAT with no separate NAT line item.
Control-plane API requests
OpenStack API calls for provisioning and management are included.
Some managed services on other clouds meter API calls or charge for premium control-plane features.
Kubernetes control plane
Magnum clusters run on Nova instances; there is no separate K8s platform fee in Quake AI pricing.
Managed Kubernetes on AWS, GCP, and Azure charges a control-plane fee on top of worker nodes.
Learn moreConfigure your estimate
Check the add-ons you plan to deploy to build a monthly total. Nothing is selected to start, so the total below begins at the baseline.
Starting template
The required baseline, always included.
Dev/test vs production
Start on shared CPU for dev/test, then promote to dedicated for production with a flavor resize. The network, storage, and template stay the same.
Dev/test on shared CPU
Burstable s1a flavors; suited to prototyping and low or bursty load.
Production on the configured CPU
The headline estimate above; predictable steady-load performance.
Saves $99.00/mo while you build on shared CPU.
Shared flavors carry less RAM (m2a.xlarge (16 GiB RAM) -> s1a.medium (4 GiB RAM)). A resize reboots the instance; data on attached volumes persists. Size the dedicated flavor for the RAM your production workload needs.
Pricing data last validated: . For current rates, check quake.ai/pricing.
Migrating an existing Kubernetes platform?#
Move a Kubernetes platform that already runs on Amazon EKS, Google GKE, Azure AKS, DigitalOcean Kubernetes (DOKS), or a self-managed cluster at another cloud. The outcome is the same workloads on a Magnum cluster on Quake AI, with container images, persistent data, and ingress cut over in a controlled order.
Follow this cutover path. Each step links an existing migration page; this section composes those pages into a workload-shaped sequence rather than duplicating their steps.
-
Map your source provider. Start with the concept-translation page for your current cloud: Coming from AWS, Coming from Azure, Coming from GCP, Coming from DigitalOcean, or Coming from Hetzner.
-
Stand up the target cluster on Quake AI. Provision the migration target with the Kubernetes cluster template.
-
Move Kubernetes workloads from the source cluster. Follow the primitive migration page for your source control plane: Migrate from EKS, Migrate from GKE, Migrate from AKS, or Migrate from DOKS.
-
Move object and artifact data. Sync container images, Helm chart archives, and backup objects with Migrate from S3 (or the matching object migration page for your source provider).
-
Cut over ingress and DNS. Publish the target ingress through a
LoadBalancerservice or an edge proxy on a floating IP. Configure TLS through your ingress controller or certificate operator, verify health checks, then switch DNS to the public address.
Workload-specific cutover callouts#
- Image registry move. Mirror container images to a registry the Magnum cluster can pull from (Quake AI-hosted registry, Docker Hub, or a registry you operate). Update image references in manifests before you drain the source cluster.
- Manifest and Helm portability. Reconcile API version differences, storage classes, and ingress annotations between the source cluster and Magnum. Run
helm templateorkubectl diffagainst the target before cutover. - Persistent volume and data migration. Snapshot or copy data bound to PersistentVolumeClaims before you reschedule stateful workloads. Validate restore on Magnum worker nodes with matching storage classes.
- Ingress and DNS cutover. Lower TTL on production hostnames several days before the switch. Drain source nodes only after the Magnum cluster passes health checks and error budgets hold.
- Workload drain and rollback. Keep the source cluster running until traffic stabilizes on Magnum. Roll back by switching DNS back and re-enabling source ingress if error rates spike.
For a hands-on walkthrough of this vertical, follow Migrate a Kubernetes platform to Quake AI.
Considerations and limits#
- You operate the control plane. Quake AI provisions the Magnum control plane inside your project; your team operates control plane availability, upgrades, backups, and certificates under the shared responsibility model.
- Bring your own add-ons. Ingress controllers, service meshes, monitoring, and storage classes are yours to install and operate. Quake AI provides the cluster and the primitives it binds to.
- Flat egress. Quake AI applies a no-egress-fee policy for outbound transfer from cluster workloads.
- Three US regions. All current regions are in the United States. Multi-region clusters require topology you design across regions.
- CPU-only compute. Worker nodes are AMD EPYC with no GPU option (compute FAQ). GPU-scheduled workloads need a different hosting path.
- Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. Where a workload requires HIPAA, PCI-DSS, FedRAMP, or ISO 27001, check the platform scope in Compliance and certifications.