> ## 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.

# Ankra Cloud Kubernetes

> Provision, import, and operate Ankra Cloud Kubernetes clusters with Ankra - a control plane the Ankra team runs in Ankra Cloud, node pools with autoscaling, upgrades, GitOps, and AI-assisted operations.

Ankra Cloud Kubernetes is the managed Kubernetes service of [Ankra Cloud](https://cloud.ankra.app). The Ankra team runs the control plane inside Ankra Cloud; Ankra creates the cluster through the Ankra Cloud API, installs the Ankra Agent, and manages everything on top - node pools, Kubernetes upgrades, add-ons, stacks, GitOps, and AI-assisted operations.

> [!WARNING]
>
> **Closed beta.** Ankra Cloud as a cluster provider is in closed beta. The workflow is stable but the surface may still change, and it is enabled per organisation on request - until it is, Ankra Cloud Kubernetes does not appear in the create-cluster dialog or among the import providers. [Contact support](https://docs.ankra.ai/platform/support.md) to have it turned on for your organisation.

This page covers Ankra Cloud Kubernetes specifically. For the shared concepts across all managed providers - live options, discovery and import, and day-2 API patterns - see [Managed Kubernetes](https://docs.ankra.ai/guides/managed-kubernetes.md). To run kubeadm or k3s yourself on Ankra Cloud servers instead, see [Ankra Cloud Clusters](https://docs.ankra.ai/guides/ankra-cloud-clusters.md).

## Prerequisites

An **Ankra Cloud credential** stored in Ankra - the same credential the self-managed clusters use. See [Ankra Cloud Credentials](https://docs.ankra.ai/platform/credentials/ankra-cloud.md). No SSH key is needed: there is no bastion and no server access.

GitOps is optional: connect a repository at creation and Ankra commits the cluster's stack definitions to Git.

## Choosing a control plane

A cluster comes in one of three shapes. You choose when you create it, and the choice cannot be changed afterwards.

| | Production control plane | Development control plane | Dev cluster |
| - | - | - | - |
| Control plane | Three replicas, run by the Ankra team | One replica, run by the Ankra team | k3s on the cluster's one server |
| Highly available | Yes | No | No |
| Control-plane fee | €40 a month per cluster | None | None |
| Nodes | Node pools, billed as servers | Node pools, billed as servers | One server, billed as a server |
| Autoscaling | Yes | Yes | No |
| Use it for | Anything that must stay up | Development, test and preview environments | A small cluster to try something on |

The **production** control plane is the default. Its three replicas keep the Kubernetes API available through an upgrade or the loss of a host node.

The **development** control plane has no fee of its own: you pay for the nodes only. It is not for production. With one replica, an upgrade or a host node failure interrupts the Kubernetes API while the control plane restarts, and you cannot deploy or change anything until it is back.

A **dev cluster** is a different shape, described in [Dev clusters](#dev-clusters).

## Creating a cluster

**Portal**

**1. Create Cluster**

Go to **Clusters** → **Create Cluster** and pick **Ankra Cloud Kubernetes** under **Cloud Managed**.

**2. Credential & Zone**

Select the Ankra Cloud credential, or add one inline, and a zone. Zones, versions and plans load live from Ankra Cloud.

**3. Node Pools**

Define one or more node pools: name, plan (with live pricing), count, labels and taints, and optionally autoscaling bounds.

**4. Kubernetes**

Pick a Kubernetes version or keep Ankra Cloud's default, and choose the control plane: production or development. Production is selected to begin with. The cost summary's control-plane row shows the fee of the one you chose, which is none for development.

**5. GitOps (optional) & Create**

Optionally connect a Git repository, then create. Ankra runs the preflight checks, creates the cluster, fetches a kubeconfig, and installs the Ankra Agent.

**API**

```bash theme={null}
curl -X POST https://platform.ankra.app/api/v1/clusters/managed/ankracloud_k8s \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-cluster",
    "credential_id": "<ankra-cloud-credential-id>",
    "location": "de-fsn1",
    "node_pools": [
      {"name": "workers", "size": "<plan>", "count": 2,
       "autoscaling": {"enabled": true, "min_count": 2, "max_count": 5}}
    ]
  }'
```

`location` is the Ankra Cloud zone and `size` is the plan name. This request creates a production control plane. For a development one, add `"ankracloud_k8s": {"control_plane": "development"}` to the body.

`GET /api/v1/clusters/managed/ankracloud_k8s/options?credential_id=<id>` lists the zones, versions and plans, and the control planes on offer in `control_planes`, each with its replica count and monthly fee.

**CLI**

```bash theme={null}
ankra cluster managed create \
  --provider ankracloud_k8s \
  --name my-cluster \
  --credential-id <ankra-cloud-credential-id> \
  --location de-fsn1 \
  --node-pool-name workers \
  --node-pool-size <plan> \
  --node-pool-count 2
```

This creates a production control plane. `--control-plane development` asks for a development one:

```bash theme={null}
ankra cluster managed create \
  --provider ankracloud_k8s \
  --name my-test-cluster \
  --credential-id <ankra-cloud-credential-id> \
  --location de-fsn1 \
  --node-pool-size <plan> \
  --node-pool-count 2 \
  --control-plane development
```

### Ankra Cloud Kubernetes options

Every option is optional and goes in an `ankracloud_k8s` block on the create request:

| Field | Default | Description |
| - | - | - |
| `private_network_id` | | An existing Ankra Cloud private network the nodes join |
| `network_cidr` | `10.0.0.0/24` | The RFC 1918 range of the network Ankra creates when `private_network_id` is not set. It must not overlap the Ankra Cloud public range `10.100.0.0/20`, and a range that does is refused |
| `public_ipv4` | `true` | Give the cluster's API endpoint a public IPv4 address, at €4 a month. The endpoint is IPv6 otherwise, and Ankra installs the agent over IPv4 |
| `control_plane` | `production` | `production` or `development`. See [Choosing a control plane](#choosing-a-control-plane). Any other value is refused, and so is `control_plane` together with `dev_cluster` |
| `dev_cluster` | `false` | Create a [dev cluster](#dev-clusters) on one server instead of a cluster with a managed control plane |

Without `private_network_id`, Ankra creates a network named `ankra-<cluster-name>` and deletes it again when the cluster is deleted. A network you named is never deleted.

### Limits

| Limit | Value |
| - | - |
| Clusters per Ankra Cloud account | 5 |
| Cluster name | 2 to 40 lowercase letters, digits or hyphens, starting with a letter |
| Node pools at creation | 8 |
| Node pool name | 2 to 32 lowercase letters, digits or hyphens, starting with a letter |
| Nodes per pool | 0 to 100 |

Preflight checks the name, zone, version and every pool's plan, and counts the account's live clusters, so a sixth cluster is refused before anything is created.

The control plane is chosen when the cluster is created and cannot be changed afterwards. To move from development to production, or back, create a new cluster and redeploy your workloads to it.

## Dev clusters

A dev cluster is one Ankra Cloud server running k3s. That server is the control plane, the only node and the cluster's own network edge, so there is no managed control plane and no control-plane fee: you pay for the one server at its plan price. It cannot autoscale and it joins no private network. Use it to try something out, not to run anything that has to stay up.

> [!WARNING]
>
> Ankra Cloud says this about every dev cluster, and the options call returns it as `production_warning`: "A dev cluster is one server: it is the Kubernetes API, the data store, every workload and the network edge. It has no high availability, no upgrades in place and no snapshots. Run production on a managed Kubernetes cluster."

Dev clusters are offered zone by zone. The `dev_cluster` block of the options call says where:

| Field | Meaning |
| - | - |
| `is_available` | Whether any zone offers dev clusters to your organisation |
| `zones` | The zones that offer one. `all_zones` is `true` when every zone does |
| `minimum_memory_mebibytes` | The memory of the smallest plan a dev cluster runs on |
| `ipv4_price_monthly` | The monthly price of a public IPv4 address for the server |
| `production_warning` | The warning above |

Create one from **Create Cluster** with the **Ankra Cloud** card labelled **Dev cluster on one server**, under **Cloud Managed**. The wizard limits the zones to the ones that offer dev clusters, asks for one server plan in place of node pools, and uses the latest stable Kubernetes release Ankra Cloud offers for dev clusters. Its cost summary prices the server and the public IPv4 address from the same options. Where no zone offers dev clusters, the wizard says they are not available for your organisation yet and creates a managed Kubernetes cluster instead.

From the CLI:

```bash theme={null}
ankra cluster managed create \
  --provider ankracloud_k8s \
  --name my-dev-cluster \
  --location <zone> \
  --node-pool-size <plan> \
  --dev-cluster
```

`--location` is a zone from `dev_cluster.zones` and `--node-pool-size` is the plan of the one server. `--dev-cluster` is refused together with `--autoscaling`, `--network-cidr`, `--private-network-id`, a `--node-pool-count` other than 1, and `--control-plane`.

On the API, set `ankracloud_k8s.dev_cluster` to `true` and send exactly one node pool with a `count` of 1, whose size is the server's plan. The request is refused when that pool enables autoscaling, when `cni` is set, and when `ankracloud_k8s.network_cidr` or `ankracloud_k8s.control_plane` is set.

## How Ankra connects

Ankra Cloud hands out a kubeconfig whose token expires eight hours after it is issued. Ankra never stores it: it fetches a fresh one each time it needs the Kubernetes API directly, installs the Ankra Agent with it at creation, and from then on works through the agent. For your own access, use [Ankra's kubeconfig](https://docs.ankra.ai/guides/kubeconfig.md) or download one from the Ankra Cloud console.

Ankra labels the cluster in Ankra Cloud with `platform.ankra.io/managed-by=ankra-platform` and `platform.ankra.io/cluster-id=<cluster-id>`, so Ankra Cloud knows the platform already manages it.

Ankra Cloud installs its own cloud controller manager and CSI driver in the cluster, so `LoadBalancer` Services get Ankra Cloud load balancers and persistent volumes use Ankra Cloud storage, with the same StorageClasses as a [self-managed cluster](https://docs.ankra.ai/guides/ankra-cloud-clusters.md#cloud-controller-and-storage). Ankra does not add a cloud-provider stack of its own.

## Verify

The create progress view follows the control plane, the node pools, kubeconfig retrieval and the Ankra Agent install. The cluster shows **Online** once the agent has connected. Then point `kubectl` at it through Ankra - this needs a [Cluster Access](https://docs.ankra.ai/guides/cluster-access.md) grant - and check that every node is `Ready`:

```bash theme={null}
ankra cluster kubeconfig add <cluster-name> --use
kubectl get nodes
```

See [Accessing Clusters with kubectl](https://docs.ankra.ai/guides/kubeconfig.md).

## Day-2 operations

* **Node pools** - add, scale and delete pools from cluster settings or the API. Labels and taints are set when a pool is created.
* **Autoscaling** - set `min_count` and `max_count` on a pool and Ankra Cloud scales it between them; clear autoscaling to return to a fixed count. See [Managed Kubernetes - day-2 operations](https://docs.ankra.ai/guides/managed-kubernetes.md#day-2-operations).
* **Upgrades** - Ankra Cloud upgrades one minor version at a time; cluster settings offer the next version when one is available.
* **Deletion** - deleting the cluster waits for Ankra Cloud to release its nodes, volumes and load balancers, then removes the network Ankra created for it.

## Cost

What a cluster costs depends on its control plane:

* **Production control plane**: €40 a month per cluster, for three replicas that keep the Kubernetes API highly available.
* **Development control plane**: no control-plane fee. You pay for the nodes only. It runs one replica and is not for production, because an upgrade or a host node failure interrupts the Kubernetes API while it restarts.
* **Dev cluster**: no control-plane fee. You pay for its one server.

Nodes are billed by Ankra Cloud as servers, at their plan price, whichever control plane you choose. A public IPv4 address on the API endpoint costs €4 a month on top, on both control planes. The wizard reads the fees live from Ankra Cloud and includes them in the cost summary.

## Importing an existing cluster

Already running Ankra Cloud Kubernetes? Discover the clusters in your Ankra Cloud account and adopt them into Ankra without touching them. See [Managed Kubernetes - importing existing clusters](https://docs.ankra.ai/guides/managed-kubernetes.md#importing-existing-clusters).

## Related

* [Managed Kubernetes overview](https://docs.ankra.ai/guides/managed-kubernetes.md)
* [Ankra Cloud Clusters](https://docs.ankra.ai/guides/ankra-cloud-clusters.md)
* [Ankra Cloud Credentials](https://docs.ankra.ai/platform/credentials/ankra-cloud.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.