Migrate a Kubernetes platform to Quake AI

In this migration guide, you move an existing Kubernetes platform to Quake AI. You stand up the Kubernetes cluster template on Magnum, sync container images and persistent data from the source cluster, and cut over ingress and DNS with a workload drain plan and rollback.

Quake AI runs a managed control plane through Magnum; worker nodes are Nova instances you size and patch. You operate cluster add-ons, ingress, and Helm releases on top of Magnum.

What you will migrate: a platform on Amazon EKS, Google GKE, Azure AKS, DigitalOcean Kubernetes (DOKS), or a self-managed cluster elsewhere.

What you will learn:

• How to provision the k8s-cluster template as the migration target
• How to pick the correct primitive migration page (EKS, GKE, AKS, or DOKS)
• How to mirror images and sync backup objects with Migrate from S3
• How to cut over ingress, drain source nodes, and roll back if workloads fail on Magnum

Time estimate: 75 minutes (excluding image mirror and PV copy time)

Prerequisites#

Before you start, confirm you have:

• kubectl access to the source cluster and cluster-admin on the target Magnum cluster after provision
• OpenTofu installed locally and application credentials for Quake AI
• Enough quota for a Magnum cluster, worker nodes, and the public IPs your ingress design requires
• The concept-translation page for your source: Coming from AWS, Coming from Azure, Coming from GCP, or Coming from DigitalOcean

Skim Deploy the Kubernetes cluster template with OpenTofu if you have not provisioned Magnum through the template before.

Step 1: Map the source provider#

Inventory namespaces, ingress hostnames, storage classes, container registries, and StatefulSets with PersistentVolumeClaims. Note API version differences between the source distribution and Magnum.

Step 2: Stand up the target cluster#

1. Download k8s-cluster.zip from the Kubernetes Cluster Bootstrap template page and unzip it into a working directory.
2. Set cluster name, node count, and flavor variables in terraform.tfvars.
3. Run tofu apply and configure kubectl against the Magnum kubeconfig output.

Record how many floating IPs your ingress design allocates. The template reference page documents the default count; add public addresses for LoadBalancer services or edge-proxy VMs when your architecture requires them.

Step 3: Move Kubernetes workloads#

Follow the primitive migration page for your source control plane:

Those pages cover manifest export, API mapping, and workload rescheduling. Run helm template or kubectl diff against Magnum before you drain production traffic.

Step 4: Move images and artifact data#

Mirror container images to a registry Magnum worker nodes can reach (Quake AI-hosted registry, Docker Hub, or a registry you operate). Update image references in manifests before cutover.

Sync Helm chart archives, backup tarballs, and checkpoint objects with Migrate from S3 when your pipeline stores artifacts in object storage.

Step 5: Migrate persistent volume data#

Snapshot or copy data bound to PersistentVolumeClaims before you reschedule stateful workloads. Validate restore on Magnum worker nodes with matching storage classes. Update PVC manifests to reference Magnum-compatible classes.

Step 6: Cut over ingress and DNS#

1. Deploy or reconfigure your ingress controller on Magnum. Publish it through a Kubernetes LoadBalancer service or an edge proxy on a floating IP.
2. Configure TLS certificates through your ingress controller or certificate operator.
3. Lower DNS TTL in advance, then point hostnames at the Magnum ingress address when health checks pass.

Workload drain and rollback: cordon and drain source nodes only after Magnum passes health checks and error budgets hold. If error rates spike, switch DNS back to the source ingress and uncordon source nodes.

Step 7: Verify the migrated platform#

• Confirm critical Deployments reach Ready state on Magnum.
• Run application smoke tests against production hostnames.
• Validate PVC mounts and database connectivity for stateful services.

Step 8: Clean up migration scaffolding#

Delete temporary mirror registries, drop staging namespaces, and decommission the source cluster only after traffic stabilizes on Magnum for the window your team requires.

What you migrated#

You moved a Kubernetes platform to Quake AI Magnum with the Kubernetes cluster template as the target, composed primitive Kubernetes and object migration pages, and cut over ingress with an explicit drain and rollback plan.

Return to the Kubernetes platforms solutions leaf for the workload-shaped migration overview.