EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Azure automatically provisions and manages the control plane at no additional cost (Free tier) or fixed fee (Standard tier with SLA), offloading health monitoring and upgrades; on Quake AI you provision a cluster through Magnum (openstack coe cluster create) or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2), and you operate the cluster after creation.
No OpenStack integration; uses Azure Resource Manager for cluster lifecycle.
Pre-configured with Azure-specific defaults and add-ons like application routing.
Managed via Azure Virtual Machine Scale Sets (VMSS) with auto-scaling and upgrades; Quake AI uses Nova instances provisioned via OpenTofu with user-managed scaling and upgrades.
This Quake AI feature maps to DigitalOcean’s Doks.
▸Google Cloud·GKE Cluster
GKE Clusterhigh
GKE provides Autopilot mode with fully managed node provisioning and scaling by Google; on Quake AI you provision clusters through Magnum or self-managed Kubernetes on Nova instances and manage node scaling yourself.
Control plane is fully managed with automatic upgrades through release channels; Quake AI requires user-provisioned and user-managed control plane nodes.
Deploy a Kubernetes cluster with master and worker nodes from an existing cluster template. The Kubernetes service provisions the VMs, networking, and stable control-plane endpoints, giving you a working cluster you can manage with kubectl.
Sufficient project quota for the planned cluster size. A minimal 1-master + 1-worker cluster on c2a.xlarge + c2a.large consumes 6000 of the default-tier 8000 compute_units budget. See Sizing and quota on the template page for the flavor-to-compute_units table; check the live total with openstack limits show --absolute before sizing.
the Console renders the Create Cluster wizard as five numbered steps: Cluster Info, Node Spec, Network Setting, Management, and Additional Labels. The bottom action bar reads Cancel | Previous: <step> | Next: <step> on steps 1 through 4, and Cancel | Previous: Management | Confirm on step 5.
Go to Kubernetes > Clusters and select Create Cluster.
Step 1: Cluster Info.
Cluster Name (required): a name for the cluster (for example, production-k8s).
Cluster Template (required): pick a template from the multi-column table. Columns are ID/Name, COE, Network Driver, and Keypair. Selecting a row places a chip below the table reading Selected: <template-name> with a clear control. Platform-provided templates include the Kubernetes version in the name (for example, Standard-V2.0-k8s-calico-fc38_v1.24.16).
Select Next: Node Spec.
Step 2: Node Spec.
Keypair (required): pick an SSH key pair for node access. The wizard exposes an inline Create Keypair button when you don't already have one. The field pre-fills with your most recently used key when at least one key pair exists in the project.
Number of Master Nodes: defaults to 1. Type 3 for a production HA control plane. A single-master cluster cannot add masters later.
Flavor of Master Nodes: select the master flavor (for example, c2a.xlarge for 4 vCPU and 8 GB RAM). Overrides the template default.
Number of Nodes: defaults to 1. Use 1 for development; size up for workload capacity.
Flavor of Nodes: select the worker flavor (for example, c2a.large for 2 vCPU and 4 GB RAM). Overrides the template default.
Select Next: Network Setting.
Step 3: Network Setting.
Enable Load Balancer: toggle on to create a single endpoint across the master nodes. The checkbox label reads Enabled Load Balancer for Master Nodes. The master_lb_floating_ip_enabled label on Step 5 controls whether the endpoint gets a floating IP. Default: off.
Enabled Network: toggle on to auto-provision a dedicated cluster network. The checkbox label reads Create New Network. Default: on. Uncheck only when you intend to attach the cluster to a pre-existing network outside this wizard.
Select Next: Management.
Step 4: Management.
Auto Healing: enable to have Magnum restart unhealthy worker nodes. The helper text under the checkbox reads Automatically repair unhealhty nodes (the Cloud Console string has a typo: unhealhty. The behavior is correct).
Auto Scaling: enable to adjust the worker count based on demand. Set min/max bounds when enabled.
Timeout(Minute): maximum minutes to wait for cluster creation. Default 60.
Select Next: Additional Labels.
Step 5: Additional Labels. This step shows the labels carried by the cluster template you selected on Step 1, with + Add Label to append more and a delete control on each row. The cluster wizard does not inject labels of its own; whatever the template carries is what you see here. A template created without labels (the Console template wizard ships empty by default) renders this step empty.
The platform requires boot_volume_size=40 for cluster creation to succeed because every Quake AI flavor family is zero-disk. Confirm boot_volume_size=40 is present (either inherited from the template or added here via + Add Label) before selecting Confirm. Without it, the cluster transitions to CREATE_FAILED within about 60 seconds with Forbidden: Only volume-backed servers are allowed for flavors with zero disk (HTTP 403). See Sizing and quota on the template page for the canonical label set the platform-provided templates carry.
Add floating_ip_enabled = false via + Add Label to suppress node-level floating IPs (combine with the template's master_lb_floating_ip_enabled = true for a 1-FIP cluster).
Select Confirm.
The cluster appears in the Clusters list with status CREATE_IN_PROGRESS. Creation typically takes 5 to 15 minutes depending on cluster size. The status changes to CREATE_COMPLETE when the cluster is ready.
Confirm the cluster status is CREATE_COMPLETE and the health status is healthy.
Open the cluster detail page by navigating directly to its URL: /container-infra/clusters/detail/<cluster-uuid>. The cluster name in the ID/Name column is not a clickable link, and the gear-menu dropdown does not include a "View detail" item; direct URL navigation is the only path to the detail page today.
The detail page surfaces fields in seven named sections:
Section
What you see
Top-level
Name, Status, Status Reason, Health Status, Created At, Updated At
Cluster Template
Name, COE
Network
Fixed Network, Fixed Subnet
Nodes
Master Node Flavor, Number of Master Nodes, Node Flavor, Number of Nodes, API Address, Master Node Addresses, Node Addresses
Additional Labels
Labels (the resolved label set: template labels plus any overrides you added on Step 5)
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.