Managed Kubernetes

Provision, import, and operate provider-managed Kubernetes clusters - DOKS, UKS, GKE, OVHcloud MKS, AKS, EKS, and Scaleway Kapsule - with Ankra.

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)

Scaleway (Kapsule)

Provider kind	Service	Credential
doks	DigitalOcean Kubernetes (DOKS)	DigitalOcean API token
uks	UpCloud Managed Kubernetes (UKS)	UpCloud API token
gke	Google Kubernetes Engine (GKE)	GCP service account key
ovh_mks	OVHcloud Managed Kubernetes (MKS)	OVHcloud application keys + Public Cloud project
aks	Azure Kubernetes Service (AKS)	Azure service principal
eks	Amazon EKS	AWS credential (access keys or IAM role)
kapsule	Scaleway Kapsule	Scaleway API key

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 Kubernetes	Self-managed
Providers	DOKS, UKS, GKE, OVHcloud MKS, AKS, EKS, Scaleway Kapsule	Hetzner, OVH, UpCloud, DigitalOcean droplets, Scaleway, Proxmox, Morpheus
Control plane	Operated by the provider	Provisioned and maintained in your account (bastion + control plane nodes)
Access model	No bastion, no SSH	SSH via a bastion; you own the nodes
Kubernetes distribution	Provider’s	k3s or kubeadm, selectable CNI, optional external etcd
Cost	Provider’s control-plane + node rates	Your compute only (no managed control-plane fee)
Stop / start	Capability-gated (AKS today)	Supported
Control-plane editing	Not applicable	Supported
Best when	Your cloud offers managed Kubernetes and you want the least to operate	You 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 all seven providers. The ankra CLI now covers all seven too (--provider doks|uks|gke|ovh_mks|aks|eks|kapsule): create, delete, stop and start (where the provider supports it), node-pool add, scale, update, and delete with autoscaling bounds, and upgrades. It still does not expose provider-specific control-plane options (HA, network plugin, SKU tier, release channel, and so on) 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:

• DOKS - DigitalOcean API token with read/write
• UKS - UpCloud API credential
• GKE - GCP service account key with the Kubernetes Engine Admin (roles/container.admin) and Service Account User (roles/iam.serviceAccountUser) roles, and the Kubernetes Engine API enabled
• OVH MKS - OVHcloud application keys with a Public Cloud project (project_id)
• AKS - Azure service principal with Contributor on the target subscription
• EKS - AWS credential with permissions for EKS, EC2, and IAM role management
• Kapsule - Scaleway API key stored in Ankra

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 for all seven 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

CLI (any provider)

# 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

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.

Stopping and starting

Stop/start is capability-gated per provider and is available for AKS only today. In the portal, use Settings → General → Danger Zone, or use the CLI:

ankra cluster managed stop <cluster_id> --provider aks
ankra cluster managed start <cluster_id> --provider aks

Stopping an AKS cluster deallocates its compute while preserving its configuration. Starting brings the same managed cluster back. The portal, CLI, API, and AI/MCP surfaces only offer these actions when the provider reports supports_stop_start.

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:

• Delete Kubernetes (the self-managed stop operation) - there is no Ankra-managed Kubernetes layer to remove. Delete the managed cluster to destroy it at the provider.
• Stop / start - capability-gated and currently available only for AKS, as described above.
• 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

Ankra’s AI can operate managed Kubernetes across all seven providers - DOKS, UKS, GKE, OVHcloud MKS, AKS, EKS, and Scaleway Kapsule. 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
• “Stop the development AKS cluster” - it proposes the capability-gated stop operation for your confirmation

Creates, imports, and lifecycle writes always require an explicit confirmation in chat before anything is submitted.

---

Troubleshooting

Issue	Solution
Options list is empty or fails	The credential is invalid or lacks API permissions - re-run Test connection on the credential
Preflight reports a quota error	Raise the provider quota (vCPUs, clusters per region) or pick another region/size
AKS create rejected with a name error	Pool names must be lowercase alphanumeric, max 12 characters; cluster names max 63
GKE create rejected with a name error	Cluster names are lowercase letters, numbers, hyphens; must start with a letter
EKS cluster stuck creating	EKS control planes routinely take 10–15 minutes; node groups follow after
Cluster shows offline after create	The 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