Kubernetes migration guides

Move your Kubernetes workloads to Quake AI from a managed Kubernetes provider or from a self-managed setup on another cloud. The core shift in most migrations is from a provider-operated control plane (EKS, GKE, AKS, DOKS) to one you operate yourself. On Quake AI you provision Kubernetes two ways: through Magnum, which builds a cluster from a curated template, or self-managed on Nova instances that you install and maintain. Coming from a self-managed source such as Kubernetes on Hetzner Cloud, you keep the self-managed model and move the underlying infrastructure to Nova instances. Either way, you gain control over the cluster, no provider lock-in on networking or storage drivers, and Quake AI's bandwidth-inclusive pricing.

Two paths to Kubernetes on Quake AI#

Quake AI provisions Kubernetes two ways. Both are supported; the right choice depends on how much control you need over the cluster's Kubernetes version, CNI, and CRI.

Magnum#

Magnum, the Container Infrastructure Management service, provisions a control plane and worker nodes from a curated cluster template (openstack coe cluster create). Platform templates ship pre-wired with Calico CNI, the OpenStack cloud-provider stack (CCM + Cinder CSI), and a load-balanced API endpoint, so a cluster is fast to stand up. You operate the cluster after creation: upgrades, node-pool sizing, and etcd backups. The Kubernetes version comes from the template catalog, so run openstack coe cluster template list to see the versions your region offers.

Self-managed on Nova instances#

Provision Nova VMs with OpenTofu, install Kubernetes using kubeadm, k3s, or RKE2, and add the OpenStack cloud-provider stack (CCM + Cinder CSI). This path gives you full control over the Kubernetes version, CNI, CRI, and upgrade cadence, which helps when you need to match a source cluster exactly or run a version outside the template catalog.

OpenTofu (openstack provider)
  -> Nova VMs (control plane x3 + worker nodes)
  -> Neutron private network
  -> stable endpoint for the K8s API
  -> kubeadm init / k3s install / rke2 install
  -> openstack-cloud-controller-manager
  -> Cinder CSI driver
  -> CNI (Calico / Cilium)

Choose your source provider#

What's portable and what's not#

Fully portable (no changes required)#

Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets (values), Namespaces, ServiceAccounts (minus cloud IAM annotations), all RBAC resources, NetworkPolicy, HPA, VPA, PodDisruptionBudget, CronJobs, and Jobs migrate without modification. Helm charts using standard Kubernetes resources deploy cleanly with updated values.

Portable with adaptation#

Provider-specific (must be replaced)#

Each provider guide documents additional provider-specific resources you must remove. Notable examples: GKE Config Connector CRDs (cnrm.cloud.google.com), the AKS Azure Policy pod, the AKS omsagent and ama-logs DaemonSets, and EKS Security Group Policies for Pods.

Operators and Helm charts that are fully portable#

cert-manager, external-dns, prometheus-operator (kube-prometheus-stack), Loki, Grafana, Velero, Istio, Linkerd, ArgoCD, Flux, ingress-nginx, Traefik, Metrics Server, and HashiCorp Vault all deploy on Quake AI without modification. Only configuration values (endpoints, credentials) change.

Recommended self-managed stack on Quake AI#

If you provision Kubernetes yourself on Nova instances, this stack is a solid starting point.

Each migration guide documents both provisioning paths. Some lead with Magnum and others with the self-managed path, depending on the source platform and how closely you need to match its Kubernetes version and CNI. See Two paths to Kubernetes on Quake AI for the trade-offs.

Data migration with Velero#

Velero is the primary tool for migrating K8s resources and persistent volume data between clusters. It backs up all API objects to object storage and uses filesystem-level backup (via node-agent) to copy PVC data independent of the source CSI driver.

For cross-provider migration, use --default-volumes-to-fs-backup so PVC data is captured at the filesystem level instead of through cloud-native snapshots.

Velero supports StorageClass remapping at restore time via a ConfigMap, so it maps source StorageClass names (like gp2, do-block-storage, hcloud-volumes) to cinder-flash on Quake AI automatically.

Migration complexity by provider#

See also#

• Migrate to Quake AI: cross-service migration hub
• Kubernetes on Quake AI: service overview
• Compute migration guides: if you also need to move non-K8s VMs
• Network migration guides: networking topology migration
• Object storage migration: if you also need to move storage