> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # Managed Kubernetes > Provision, import, and operate provider-managed Kubernetes clusters - DOKS, UKS, GKE, OVHcloud MKS, AKS, and EKS - 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: | Provider kind | Service | Credential | | ------------- | ------------------------------------------------------------- | ------------------------------------------------ | | `doks` | [DigitalOcean Kubernetes (DOKS)](/guides/doks-clusters) | DigitalOcean API token | | `uks` | [UpCloud Managed Kubernetes (UKS)](/guides/uks-clusters) | UpCloud API token | | `gke` | [Google Kubernetes Engine (GKE)](/guides/gke-clusters) | GCP service account key | | `ovh_mks` | [OVHcloud Managed Kubernetes (MKS)](/guides/ovh-mks-clusters) | OVHcloud application keys + Public Cloud project | | `aks` | [Azure Kubernetes Service (AKS)](/guides/aks-clusters) | Azure service principal | | `eks` | [Amazon EKS](/guides/eks-clusters) | AWS 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](/guides/hetzner-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 | Hetzner, OVH, UpCloud, DigitalOcean droplets, [Proxmox](/guides/proxmox-clusters), [Morpheus](/guides/morpheus-clusters) | | 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, 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 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](/platform/credentials) for the per-provider setup: * **DOKS** - [DigitalOcean API token](/platform/credentials/digitalocean) with read/write * **UKS** - [UpCloud API credential](/platform/credentials/upcloud) * **GKE** - [GCP service account key](/platform/credentials/gcp) 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](/platform/credentials/ovh) with a Public Cloud project (`project_id`) * **AKS** - [Azure service principal](/platform/credentials/azure) with **Contributor** on the target subscription * **EKS** - [AWS credential](/platform/credentials/aws) with permissions for EKS, EC2, and IAM role management 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: ```bash theme={null} curl "https://platform.ankra.app/org/clusters/managed/eks/options?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 Go to **Clusters** → **Create Cluster** and pick your provider's **Cloud Managed** action. Select the provider credential and a region. Locations load live from the provider. Define one or more worker pools: name, node size (with live pricing and a monthly cost summary), count, labels, and - where supported - autoscaling bounds. 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). Connect a Git repository so the cluster's stacks are committed to Git. 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 ```bash theme={null} ankra cluster managed create \ --provider doks \ --name my-doks-cluster \ --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 ```bash theme={null} 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": "", "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](/reference/managed-kubernetes#provider-specific-option-blocks): [DOKS](/guides/doks-clusters) · [UKS](/guides/uks-clusters) · [GKE](/guides/gke-clusters) · [OVH MKS](/guides/ovh-mks-clusters) · [AKS](/guides/aks-clusters) · [EKS](/guides/eks-clusters) *** ## 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): ```bash theme={null} # list clusters at the provider for a credential curl "https://platform.ankra.app/org/clusters/managed/eks/discover?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": "", "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 ```bash CLI (any provider) theme={null} # add a pool ankra cluster managed node-pool add --provider doks --name pool-b --size s-4vcpu-8gb --count 2 # scale a pool ankra cluster managed node-pool scale workers --provider doks --count 5 # delete a pool ankra cluster managed node-pool delete pool-b --provider doks ``` ```bash cURL (any provider) theme={null} # update count and/or autoscaling bounds curl -X PATCH https://platform.ankra.app/org/clusters/managed/doks//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: ```bash theme={null} ankra cluster managed upgrade --provider doks --version 1.33.0 ``` The provider upgrades the control plane first, then rolls node pools. Downgrades are not supported. ### Deleting ```bash theme={null} ankra cluster managed delete --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](/platform/cluster-settings) 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 | 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** |