Migrate from Linode Kubernetes Engine (LKE) to Kubernetes on Quake AI

Service mapping#

1. Overview#

Linode Kubernetes Engine (LKE) is Akamai Cloud Computing's managed Kubernetes service. LKE ships vanilla upstream Kubernetes with a small set of Linode-specific add-ons: the linode-cloud-controller-manager (handles Service type: LoadBalancer provisioning of NodeBalancers and node lifecycle), the linode-blockstorage CSI driver, and the optional Linode Container Registry for images. LKE offers a free Standard tier (single control plane in a region) and a paid Enterprise tier with HA control plane and SLA.

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. LKE 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. LKE 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 'linode-loadbalancer' > linode-lb-services.txt

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

Inventory checklist:

• All PVCs using linode-block-storage or linode-block-storage-retain StorageClass
• All Services with service.beta.kubernetes.io/linode-loadbalancer-* annotations
• Images hosted on the Linode Container Registry
• Helm releases and versions
• external-dns configuration (if using a managed DNS provider)
• Any references to LINODE_TOKEN or LINODE_API_TOKEN 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: Linode Block Storage to Cinder#

Replace the StorageClass reference in all PVCs:

# Before (LKE)
storageClassName: linode-block-storage

# After (Quake AI)
storageClassName: cinder-flash

LKE volumes are standard RWO block storage; Cinder is a 1:1 replacement. LKE's linode-block-storage-retain StorageClass (which keeps the underlying volume on PVC delete) is equivalent to a Cinder StorageClass with reclaimPolicy: Retain; if you depended on the retain behavior, create or use a matching StorageClass.

Ingress controller#

If your LKE 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 linode-cloud-controller-manager to provision NodeBalancers directly through Service type: LoadBalancer, remove Linode-specific annotations:

# Remove these Linode-specific annotations from Service manifests
service.beta.kubernetes.io/linode-loadbalancer-throttle
service.beta.kubernetes.io/linode-loadbalancer-default-protocol
service.beta.kubernetes.io/linode-loadbalancer-port-NN
service.beta.kubernetes.io/linode-loadbalancer-tls-NN
service.beta.kubernetes.io/linode-loadbalancer-hostname-only-ingress
service.beta.kubernetes.io/linode-loadbalancer-firewall-id

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

Pod identity#

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

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

# Before: external-dns with Linode DNS
args:
  - --provider=linode

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

Service type LoadBalancer#

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

Container images: Linode Container Registry to a portable registry#

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

docker pull lc.<region>.linodeobjects.com/MY_NAMESPACE/MY_IMAGE:TAG
docker tag  lc.<region>.linodeobjects.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 an LKE migration.

6. Apply and validate#

Migrate data with Velero:

# On LKE: install Velero with an S3-compatible backend
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket lke-migration \
  --use-node-agent \
  --default-volumes-to-fs-backup \
  --backup-location-config \
    region=us-east-1,s3ForcePathStyle=true,s3Url=https://us-east-1.linodeobjects.com

velero backup create lke-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:
  linode-block-storage: cinder-flash
  linode-block-storage-retain: cinder-flash
EOF

velero restore create --from-backup lke-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 LKE 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.

LKE's basic node and cluster metrics in the Linode Cloud Manager have no equivalent on Quake AI. All monitoring is self-managed.

8. Auto-scaling alternatives#

LKE 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 linode-loadbalancer-* annotations remaining
• No Linode Container Registry image references remaining
• No LINODE_TOKEN Secrets remaining (unless an external Linode 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 Linode: cross-service Linode migration hub
• Coming from Linode: concept-translation reference
• Network migration from Linode VPC: networking-specific migration
• Object storage migration from Linode: storage migration