Skip to main content
Ankra provisions and manages provider-native managed Kubernetes: the cloud provider runs the control plane, and Ankra handles everything on top - node pools, Kubernetes upgrades, addons, stacks, GitOps, and AI-assisted operations. This page is the shared overview. Each provider has its own guide with the specifics:

DigitalOcean (DOKS)

UpCloud (UKS)

Google (GKE)

OVHcloud (MKS)

Azure (AKS)

Amazon (EKS)

Provider kindServiceCredential
doksDigitalOcean Kubernetes (DOKS)DigitalOcean API token
uksUpCloud Managed Kubernetes (UKS)UpCloud API token
gkeGoogle Kubernetes Engine (GKE)GCP service account key
ovh_mksOVHcloud Managed Kubernetes (MKS)OVHcloud application keys + Public Cloud project
aksAzure Kubernetes Service (AKS)Azure service principal
eksAmazon EKSAWS credential (access keys or IAM role)

​
Managed vs self-managed

Ankra provisions two kinds of clusters. Managed Kubernetes (this page) is usually the fastest path if your provider offers it; self-managed clusters give you full control of the control plane and run anywhere you have compute.
Managed KubernetesSelf-managed
ProvidersDOKS, UKS, GKE, OVHcloud MKS, AKS, EKSHetzner, OVH, UpCloud, DigitalOcean droplets, Proxmox, Morpheus
Control planeOperated by the providerProvisioned and maintained in your account (bastion + control plane nodes)
Access modelNo bastion, no SSHSSH via a bastion; you own the nodes
Kubernetes distributionProvider’sk3s or kubeadm, selectable CNI, optional external etcd
CostProvider’s control-plane + node ratesYour compute only (no managed control-plane fee)
Stop / start, control-plane editingNot applicableSupported
Best whenYour cloud offers managed Kubernetes and you want the least to operateYou run on-prem or want full control of the control plane
Both kinds get the same Ankra day-2 surface: stacks, GitOps, addons, node groups, upgrades, and AI-assisted operations.
Surface coverage. The portal, API, and AI assistant cover the full feature set for all six providers. The ankra CLI creates, deletes, scales node pools, and upgrades all six providers (--provider doks|uks|gke|ovh_mks|aks|eks), but does not expose provider-specific control-plane options (HA, network plugin, SKU tier, release channel, and so on), node-pool autoscaling bounds, or cluster discovery and import. For those, use the portal or the API.

​
Prerequisites

One provider credential, stored in Ankra. See Credentials for the per-provider setup: GitOps is optional: connect a repository during creation and Ankra commits the cluster’s stack definitions to Git.

​
Live options and pricing

Every choice in the create flow is fetched live from the provider with your credential - regions, Kubernetes versions (with support windows), node sizes, and prices, including spot capacity and quota-aware availability where the provider exposes it. Nothing is hardcoded, so new instance families and price changes show up automatically. The create wizard renders these options for you; you can also fetch them from the API: 
curl "https://platform.ankra.app/org/clusters/managed/eks/options?credential_id=<aws-credential-id>" \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"
The response lists locations, versions / version_options (with supported_until where the provider publishes it), sizes (vCPUs, memory, disk, GPU, monthly price), cluster_plans, and capabilities (spot, autoscaling, autopilot, private endpoint, HA control plane).

​
Creating a managed cluster

​
Via the Platform UI

1

Navigate to Clusters

Go to Clusters → Create Cluster and pick your provider’s Cloud Managed action.
2

Credential & Location

Select the provider credential and a region. Locations load live from the provider.
3

Node Pools

Define one or more worker pools: name, node size (with live pricing and a monthly cost summary), count, labels, and - where supported - autoscaling bounds.
4

Kubernetes

Pick a Kubernetes version (or keep the provider default) and any provider-specific control plane options - HA (DOKS), control-plane plan (UKS), release channel / Autopilot (GKE), plan and update policy (OVH MKS), network plugin, private cluster and SKU tier (AKS), or subnets and control-plane logging (EKS).
5

GitOps (optional)

Connect a Git repository so the cluster’s stacks are committed to Git.
6

Preflight & Create

Ankra runs provider preflight checks (credential validity, quota, name availability) before submitting. Failures block creation; warnings are shown for review. A live progress view then tracks control plane provisioning, node pools, kubeconfig retrieval, and Ankra Agent installation.

​
Via the CLI

ankra cluster managed create \
  --provider doks \
  --name my-doks-cluster \
  --credential-id <do-credential-id> \
  --location fra1 \
  --node-pool-name workers \
  --node-pool-size s-2vcpu-4gb \
  --node-pool-count 2
The CLI’s --provider flag accepts doks, uks, gke, ovh_mks, aks, and eks. Optional flags are --kubernetes-version and the GitOps trio (--gitops-credential-name, --gitops-repository, --gitops-branch). The CLI create sends a single initial node pool; provider-specific control-plane options (HA, network plugin, release channel, SKU tier, and so on) and node-pool autoscaling bounds are set from the portal or the API below.

​
Via the API

curl -X POST https://platform.ankra.app/org/clusters/managed/aks \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-aks-cluster",
    "credential_id": "<azure-credential-id>",
    "location": "westeurope",
    "kubernetes_version": "1.32.3",
    "node_pools": [
      {
        "name": "workers",
        "size": "Standard_D2s_v5",
        "count": 2,
        "autoscaling": {"enabled": true, "min_count": 2, "max_count": 5}
      }
    ],
    "aks": {"network_plugin": "azure", "sku_tier": "Standard"}
  }'
Run the same payload against POST /org/clusters/managed/{provider}/preflight first to get the provider checks without creating anything.

​
Provider-specific options

Each provider takes its own control-plane and networking options - HA (DOKS), control-plane plan (UKS), release channel and Autopilot (GKE), plan and update policy (OVH MKS), network plugin and SKU tier (AKS), or subnets and control-plane logging (EKS). The exact fields for each are documented on the per-provider pages and in the Managed Kubernetes reference: DOKS · UKS · GKE · OVH MKS · AKS · EKS

​
Importing existing clusters

Already running managed Kubernetes? Discover clusters at the provider and adopt them into Ankra without touching them. Discovery and import run from the portal or the API (all six providers): 
# list clusters at the provider for a credential
curl "https://platform.ankra.app/org/clusters/managed/eks/discover?credential_id=<aws-credential-id>" \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

# adopt one into Ankra
curl -X POST https://platform.ankra.app/org/clusters/managed/eks/import \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "credential_id": "<aws-credential-id>",
    "provider_cluster_id": "<provider-cluster-id>",
    "name": "imported-prod"
  }'
In the portal, use Clusters → Import Cluster → your provider. Discovery marks clusters that are already imported, so you can’t adopt the same cluster twice. After import, Ankra fetches the kubeconfig, installs the Ankra Agent, and the cluster gains the same day-2 operations as clusters Ankra created.

​
Day-2 operations

​
Node pools

# add a pool
ankra cluster managed node-pool add <cluster_id> --provider doks --name pool-b --size s-4vcpu-8gb --count 2

# scale a pool
ankra cluster managed node-pool scale <cluster_id> workers --provider doks --count 5

# delete a pool
ankra cluster managed node-pool delete <cluster_id> pool-b --provider doks

# update count and/or autoscaling bounds
curl -X PATCH https://platform.ankra.app/org/clusters/managed/doks/<cluster_id>/node-pools/workers \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"autoscaling": {"enabled": true, "min_count": 2, "max_count": 10}}'
The CLI scales node pools to a fixed count on any provider. Autoscaling bounds (available on every provider except UKS, which UpCloud does not support) are set from the portal or the PATCH endpoint above. AKS pool names are lowercase alphanumeric and at most 12 characters.

​
Kubernetes upgrades

Ankra lists the upgrade targets the provider actually offers for your cluster’s current version. In the portal, Settings → General → Kubernetes Version shows available upgrades with their support windows. You can also upgrade any provider from the CLI: 
ankra cluster managed upgrade <cluster_id> --provider doks --version 1.33.0
The provider upgrades the control plane first, then rolls node pools. Downgrades are not supported.

​
Deleting

ankra cluster managed delete <cluster_id> --provider doks
Deleting a managed cluster destroys it at the provider - control plane, node pools, and workloads. Clean up provider-created LoadBalancers and volumes first if the CCM/CSI created any outside the cluster’s own resource group or VPC.

​
What does not apply to managed clusters

Because the provider owns the control plane, some lifecycle operations that exist for self-managed clusters are not applicable here:
  • Stop / start and Delete Kubernetes (deprovision) - there is no Ankra-managed compute to release; use the provider’s own controls or delete the cluster.
  • Control-plane topology editing (controller count, control-plane instance type) - the provider sizes and manages the control plane. HA control planes, where offered, are selected at creation.
  • Instance-type upgrade in place - change node sizing by editing or replacing a node pool, not by resizing individual nodes.

​
Ankra AI

The Ankra AI assistant can operate managed Kubernetes across all six providers, the same as the portal and API. Ask it to:
  • “What does a 3-node e2-standard-4 GKE cluster in europe-west1 cost?” - it fetches live options and pricing with your credential
  • “Create an AKS cluster in West Europe with autoscaling 2–5 nodes” - it proposes the create for your confirmation
  • “What EKS clusters exist in our AWS account?” - it discovers clusters at the provider and shows which are already imported
  • “Import the staging GKE cluster” - it adopts a discovered cluster after you confirm
Creates and imports always require an explicit confirmation in chat before anything is submitted.

​
Troubleshooting

IssueSolution
Options list is empty or failsThe credential is invalid or lacks API permissions - re-run Test connection on the credential
Preflight reports a quota errorRaise the provider quota (vCPUs, clusters per region) or pick another region/size
AKS create rejected with a name errorPool names must be lowercase alphanumeric, max 12 characters; cluster names max 63
GKE create rejected with a name errorCluster names are lowercase letters, numbers, hyphens; must start with a letter
EKS cluster stuck creatingEKS control planes routinely take 10–15 minutes; node groups follow after
Cluster shows offline after createThe agent installs as the last step - check the operation timeline on the cluster page
Import says “already imported”The cluster is connected to this or another Ankra organisation; find it in Clusters