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

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 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. To run kubeadm or k3s yourself on Ankra Cloud servers instead, see Ankra Cloud Clusters.

Prerequisites

An Ankra Cloud credential stored in Ankra - the same credential the self-managed clusters use. See Ankra Cloud Credentials. 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.

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

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

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:

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. Any other value is refused, and so is control_plane together with dev_cluster
dev_cluster	false	Create a dev cluster 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.

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:

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 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. 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 grant - and check that every node is Ready:

ankra cluster kubeconfig add <cluster-name> --use
kubectl get nodes

See Accessing Clusters with kubectl.

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

Related

• Managed Kubernetes overview
• Ankra Cloud Clusters
• Ankra Cloud Credentials