Migrate from Vultr Kubernetes Engine (VKE) to Kubernetes on Quake AI

Service mapping#

1. Overview#

Vultr Kubernetes Engine (VKE) is Vultr's managed Kubernetes service. VKE ships vanilla upstream Kubernetes with a small set of Vultr-specific add-ons: a Vultr cloud controller manager (handles Service type: LoadBalancer provisioning of Vultr Load Balancers and node lifecycle), a Vultr Block Storage CSI driver, and integration with the Vultr Container Registry for images. VKE offers a free control plane (single region) and optional HA control plane upgrades.

On Quake AI, you provision Kubernetes through Magnum, the Container Infrastructure Management service. Magnum gives you a control plane and worker nodes from a curated cluster template (openstack coe cluster create). The us-east-1 region ships platform templates pre-wired with Calico CNI, the OpenStack cloud-provider stack (CCM + Cinder CSI), and a load-balanced API endpoint. Run openstack coe cluster template list for the current template catalog and Kubernetes versions, or see the cluster templates reference.

For teams that need a non-Magnum stack (custom CNI, custom kubelet flags, custom CRI, or a Kubernetes version outside the template catalog), self-managed RKE2 or k3s on Nova instances is documented as an alternative later in this tutorial. VKE users accustomed to a fully managed control plane should plan for the operational shift: on Magnum you own the cluster after creation (upgrades, node-pool sizing, etcd backups), and on the self-managed path you also own the bootstrap, the CNI, and the CCM/CSI install.

Migration complexity: Low to medium. VKE has no IRSA-style pod identity, no proprietary CNI, and only a handful of vendor-specific annotations. The primary tasks are swapping the CCM and CSI driver, mirroring container images, and rebuilding a stable Kubernetes API endpoint. Expect 1 to 2 weeks for a typical production migration.

2. Workload portability matrix#

3. Pre-migration: export and audit#

kubectl get all --all-namespaces -o yaml > cluster-export.yaml

kubectl get pvc,pv --all-namespaces -o yaml > storage.yaml

kubectl get svc --all-namespaces -o yaml | grep 'vultr-loadbalancer' > vultr-lb-services.txt

helm list --all-namespaces > helm-releases.txt

Inventory checklist:

• All PVCs using vultr-block-storage StorageClass
• All Services with service.beta.kubernetes.io/vultr-loadbalancer-* annotations
• Images hosted on the Vultr Container Registry
• Helm releases and versions
• external-dns configuration (if using a managed DNS provider)
• Any references to VULTR_API_KEY in Secrets

4. Provision Kubernetes on Quake AI#

4.1 Primary path: Magnum#

Provision a cluster from a Magnum template. The platform creates the control plane VMs, worker VMs, security groups, networking, and a stable endpoint for the Kubernetes API.

openstack coe cluster template list
openstack coe cluster create production-k8s \
  --cluster-template Standard-v2.0-k8s-calico-fc38_v1.24.16 \
  --master-count 3 \
  --node-count 3 \
  --keypair MY_KEYPAIR

For the full walkthrough including Console and quota guidance, see Create a Kubernetes cluster. To roll your own template (custom flavors, alternate Kubernetes version), see Create a cluster template.

Once the cluster reports CREATE_COMPLETE, fetch the kubeconfig:

openstack coe cluster config production-k8s --dir ~/.kube
kubectl get nodes
kubectl get storageclass

The template pre-installs the Cinder CSI driver and the OpenStack cloud-provider stack; the Magnum path needs no manual CCM, CSI, or CNI install.

4.2 Alternative: self-managed RKE2 or k3s#

If the Magnum template catalog does not match your version, CNI, or CRI constraints, build the cluster yourself on Nova instances. Use OpenTofu with the openstack provider to create the infrastructure:

• Neutron network + subnet
• Security groups (Kubernetes API 6443, NodePort 30000-32767, inter-node)
• Nova instances: 3 control plane + N workers
• Stable endpoint for the Kubernetes API

Install RKE2 or k3s, then deploy on the cluster:

1. openstack-cloud-controller-manager with application credentials
2. Cinder CSI driver with the cinder-flash StorageClass
3. Calico (VXLAN) or Cilium as the CNI

# Example: minimal RKE2 control plane bootstrap on a Nova instance
curl -sfL https://get.rke2.io | sh -
sudo systemctl enable --now rke2-server
sudo cat /etc/rancher/rke2/rke2.yaml  # kubeconfig

Point the kubeconfig server: value at the control-plane endpoint on port 6443.

5. Adapt provider-specific resources#

CSI driver: Vultr Block Storage to Cinder#

Replace the StorageClass reference in all PVCs:

# Before (VKE)
storageClassName: vultr-block-storage

# After (Quake AI)
storageClassName: cinder-flash

VKE volumes are standard RWO block storage; Cinder is a 1:1 replacement. If you depended on a retain-on-delete behavior, create or use a Cinder StorageClass with reclaimPolicy: Retain.

Ingress controller#

If your VKE cluster already uses nginx-ingress (the most common pattern), no ingress changes are needed beyond DNS updates. nginx-ingress is fully portable.

If you used the Vultr cloud controller manager to provision Vultr Load Balancers directly through Service type: LoadBalancer, remove Vultr-specific annotations:

# Remove these Vultr-specific annotations from Service manifests
service.beta.kubernetes.io/vultr-loadbalancer-algorithm
service.beta.kubernetes.io/vultr-loadbalancer-protocol
service.beta.kubernetes.io/vultr-loadbalancer-ssl
service.beta.kubernetes.io/vultr-loadbalancer-sticky-sessions
service.beta.kubernetes.io/vultr-loadbalancer-healthcheck-path
service.beta.kubernetes.io/vultr-loadbalancer-firewall-rules

The cloud controller assigns public endpoints to Kubernetes Services with type: LoadBalancer without requiring provider-specific annotations.

Pod identity#

VKE has no IAM-for-pods mechanism. Pods on VKE that call Vultr APIs (for example, external-dns with the Vultr DNS provider) use long-lived API keys stored in K8s Secrets.

• Remove any VULTR_API_KEY Secret references that are not still required.
• For applications that called Vultr APIs, reconfigure to point at the target service:

# Before: external-dns with Vultr DNS
args:
  - --provider=vultr

# After: external-dns with Cloudflare (or other)
args:
  - --provider=cloudflare

Service type LoadBalancer#

The standard Kubernetes LoadBalancer Service fields remain portable. Remove any vultr-loadbalancer-* annotations before applying on Quake AI.

Container images: Vultr Container Registry to a portable registry#

The Vultr Container Registry is Vultr-specific. Mirror all images before cutover:

docker pull <region>.vultrcr.com/MY_NAMESPACE/MY_IMAGE:TAG
docker tag  <region>.vultrcr.com/MY_NAMESPACE/MY_IMAGE:TAG docker.io/ORG/MY_IMAGE:TAG
docker push docker.io/ORG/MY_IMAGE:TAG

Update all Deployment and StatefulSet manifests with the new image references. This is the most manual step in a VKE migration.

6. Apply and validate#

Migrate data with Velero:

# On VKE: install Velero with an S3-compatible backend
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket vke-migration \
  --use-node-agent \
  --default-volumes-to-fs-backup \
  --backup-location-config \
    region=ewr,s3ForcePathStyle=true,s3Url=https://ewr1.vultrobjects.com

velero backup create vke-full --include-namespaces production

# On Quake AI: restore with StorageClass remapping
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: change-storage-class-config
  namespace: velero
  labels:
    velero.io/plugin-config: ""
    velero.io/change-storage-class: RestoreItemAction
data:
  vultr-block-storage: cinder-flash
EOF

velero restore create --from-backup vke-full --restore-volumes=true

Deploy and verify:

kubectl get pods --all-namespaces -o wide
kubectl get pvc --all-namespaces
kubectl get svc --all-namespaces

For stateful workloads (databases), prefer application-level dump/restore (pg_dump, mysqldump) over Velero filesystem backup for guaranteed consistency.

7. Observability setup#

Most VKE users already run self-managed Prometheus + Grafana. If so, these migrate as-is; only PVC StorageClass references need updating.

If starting fresh, install the self-managed observability stack:

helm upgrade --install kube-prometheus-stack \
  prometheus-community/kube-prometheus-stack \
  --version 72.9.1 \
  --namespace monitoring --create-namespace

helm upgrade --install loki grafana/loki-stack \
  --namespace monitoring \
  --set promtail.enabled=true \
  --set loki.persistence.storageClassName=cinder-flash

Match the chart version to your cluster's Kubernetes version. From chart version 73.0.0 the kube-prometheus-stack chart requires Kubernetes 1.25 or later. Quake AI Magnum cluster templates run Kubernetes 1.24.16, so pin --version 72.9.1, the last chart release that supports 1.24. On a cluster running Kubernetes 1.25 or later, omit the --version flag to install the current chart.

VKE's basic node and cluster metrics in the Vultr Customer Portal have no equivalent on Quake AI. All monitoring is self-managed.

8. Auto-scaling alternatives#

VKE node-pool autoscaling supports min/max bounds per pool. The equivalent on Quake AI is the OpenStack Cluster Autoscaler or manual scaling of the OpenTofu-managed worker pool.

9. Validation checklist#

• All pods in Running or Completed state
• PVCs bound to Cinder volumes with correct data
• Ingress routes working through the ingress controller's public LoadBalancer Service
• DNS resolves to new Floating IPs
• Prometheus scraping all targets
• No vultr-loadbalancer-* annotations remaining
• No Vultr Container Registry image references remaining
• No VULTR_API_KEY Secrets remaining (unless an external Vultr integration is still required)
• StatefulSet data integrity verified
• Application health checks passing

10. Provider-specific gotchas#

See also#

• Kubernetes migration overview: all provider guides and portability matrix
• Migrating from Vultr: cross-service Vultr migration hub
• Coming from Vultr: concept-translation reference
• Network migration from Vultr VPC: networking-specific migration
• Object storage migration from Vultr: storage migration