OVH Clusters - Ankra Platform

Ankra supports provisioning fully managed Kubernetes clusters on OVH Cloud. You can create clusters with configurable control planes, workers, and networking - then scale workers up or down as needed.

Prerequisites

Before creating an OVH cluster, you need two credentials:

OVH API Credential

OVH Cloud API credentials (application key, application secret, consumer key, and project ID). See OVH API Credentials.

SSH Key Credential

An SSH public key for server access. You can provide your own or let Ankra generate one. See SSH Key Credentials.

Creating an OVH Cluster

Via the Platform UI

A guided wizard walks you through creating an OVH cluster - select credentials, pick a region, choose instance flavors (general purpose, CPU-optimized, or RAM-optimized), set control plane and worker counts, and launch.

Navigate to Clusters

Go to Clusters in the Ankra dashboard and click Create Cluster.

Select OVH Cloud

Choose OVH Cloud as the provider.

Select Credentials

Pick your OVH API credential and SSH key credential from the dropdowns. You can also create new credentials directly from the wizard.

Choose Region

Select an OVH Cloud region (e.g., Gravelines, Strasbourg, Beauharnois, Warsaw, London, Frankfurt). Each region shows the location and country.

Configure Nodes

Set your cluster topology:

Gateway - instance flavor for the SSH gateway (e.g., b2-7)
Control Plane - count and flavor (e.g., 1x b2-15)
Workers - count and flavor (e.g., 2x b2-15)

The wizard shows vCPUs, RAM, disk, and hourly cost for each flavor to help you choose.

Create & Track Progress

Click Create to start provisioning. A live progress view tracks every step - network creation, gateway setup, control plane provisioning, worker provisioning, k3s installation, and Ankra Agent setup. The cluster appears with an offline state until provisioning completes, then transitions to online.

Managing from the Dashboard

Once your OVH cluster is online, you can manage it directly from the Ankra dashboard:

Scale workers - go to Cluster Settings → General to scale worker nodes up or down
Upgrade Kubernetes - upgrade the k3s version from cluster settings
Deprovision - delete the cluster and all OVH resources from the Danger Zone in cluster settings

Via the CLI

# Create credentials first
ankra credentials ovh create --name my-ovh-cred --project-id <project-id>
# You will be prompted for application key, application secret, and consumer key

ankra credentials ovh ssh-key create --name my-ssh-key --generate

# Create the cluster
ankra cluster ovh create \
  --name my-cluster \
  --credential-id <ovh-credential-id> \
  --ssh-key-credential-id <ssh-key-credential-id> \
  --region GRA7 \
  --control-plane-count 1 \
  --control-plane-flavor-id b2-15 \
  --worker-count 2 \
  --worker-flavor-id b2-15

Via the API

curl -X POST https://platform.ankra.app/api/v1/clusters/ovh \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-cluster",
    "credential_id": "<ovh-credential-id>",
    "ssh_key_credential_id": "<ssh-key-credential-id>",
    "region": "GRA7",
    "control_plane_count": 1,
    "control_plane_flavor_id": "b2-15",
    "worker_count": 2,
    "worker_flavor_id": "b2-15",
    "distribution": "k3s"
  }'

Every configuration parameter, the region list, and instance flavors are in the OVH Reference.

Node Groups

Node groups let you organize worker nodes into logical groups with independent instance flavors, counts, labels, and taints. Manage node groups from Settings > Nodes in the dashboard, or via the API.

Node Group API Reference

All node-group operations are also available via the REST API - see the OVH Node Group API. From the CLI, a node group can be created with its Kubernetes labels and taints in one step, and existing groups can be scaled, re-flavored, relabeled, retainted, or deleted:

ankra cluster ovh node-group list <cluster_id>
ankra cluster ovh node-group add <cluster_id> \
  --name gpu --instance-type b2-30 --count 2 \
  --labels tier=gold,workload=ml \
  --taints dedicated=gpu:NoSchedule
ankra cluster ovh node-group scale <cluster_id> gpu 3
ankra cluster ovh node-group labels <cluster_id> gpu --labels tier=gold
ankra cluster ovh node-group taints <cluster_id> gpu --taints dedicated=gpu:NoSchedule
ankra cluster ovh node-group delete <cluster_id> gpu

Labels and taints are applied to every node in the group; passing an empty value clears them, and a taint effect defaults to NoSchedule. For detailed usage examples, see Hetzner Node Groups - the API is identical across all providers.

Legacy Worker Scaling

The legacy scale-workers and worker-count endpoints still work for backward compatibility.

ankra cluster ovh workers <cluster_id>
ankra cluster ovh scale <cluster_id> 4

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/worker-count \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

curl -X POST https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/scale-workers \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"worker_count": 4}'

For new clusters, prefer using Node Groups for more granular control.

Upgrading Kubernetes Version

You can upgrade the Kubernetes (k3s) version on all nodes in an OVH cluster. Upgrades are applied to control plane nodes first, then workers.

Only k3s clusters are supported for version upgrades.
Downgrades are not supported - k3s downgrades require an etcd snapshot restore.
You can only upgrade one minor version at a time (e.g., v1.33.x to v1.34.x, not v1.33.x to v1.35.x).
The cluster must be online with no active operations.

Via the Dashboard

Go to your cluster → Settings → General to see the current k3s version and trigger an upgrade.

Check Current Version

ankra cluster ovh k8s-version <cluster_id>

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/k8s-version \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

Response:

{
  "current_version": "v1.34.4+k3s1",
  "distribution": "k3s"
}

Upgrade Version

ankra cluster ovh upgrade <cluster_id> v1.35.1+k3s1

curl -X POST https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/upgrade-k8s-version \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target_version": "v1.35.1+k3s1"}'

Response:

{
  "previous_version": "v1.34.4+k3s1",
  "new_version": "v1.35.1+k3s1",
  "nodes_affected": 3
}

Stopping and Starting a Cluster

You can stop an OVH cluster to release its compute (instances, gateway, and managed gateway) while keeping its configuration, networking definition, and SSH keys. Starting the cluster re-provisions the compute and reconciles it back to a running state. This is useful for pausing non-production clusters to save cost. When starting, use --scope control_plane to bring up only the control plane first (for example to inspect or repair it), or --scope all (the default) to provision the whole cluster.

ankra cluster ovh stop <cluster_id>
ankra cluster ovh start <cluster_id>                       # scope defaults to "all"
ankra cluster ovh start <cluster_id> --scope control_plane # control plane only

curl -X POST https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/stop \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

curl -X POST "https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/start?scope=all" \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

Stop and start are background operations. A start returns 409 if a stop or terminate operation is still running. The private network is preserved while stopped and reused on the next start.

SSH Access and Keys

ankra cluster ovh access-info prints the gateway (bastion) and control plane IPs along with ready-to-paste ssh -J jump and Kubernetes API port-forward commands, so you can reach nodes behind the gateway without looking up IPs by hand.

ankra cluster ovh access-info <cluster_id>

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/access-info \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

You can also view and replace the SSH key credentials attached to a cluster. Replacing the keys applies on the next reconciliation.

ankra cluster ovh ssh-keys get <cluster_id>
ankra cluster ovh ssh-keys set <cluster_id> --ssh-key-credential-ids <id>,<id>

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/ssh-keys \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

curl -X PUT https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/ssh-keys \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ssh_key_credential_ids": ["<ssh-key-credential-id>"]}'

Managing the Control Plane

Inspect the control plane configuration, then change the node count or instance flavor. OVH control planes support a count of 1 or 3.

ankra cluster ovh control-plane get <cluster_id>
ankra cluster ovh control-plane set-count <cluster_id> 3
ankra cluster ovh control-plane set-instance-type <cluster_id> b2-15

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/control-plane \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

curl -X PUT https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/control-plane \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"count": 3}'

curl -X PUT https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/control-plane/instance-type \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"instance_type": "b2-15"}'

Control plane changes require the cluster to be stopped first. Changing the count or instance type on a running cluster returns 409 with “The cluster must be stopped” - stop it, apply the change, then start it again.

Inspecting Nodes

List every node in the cluster or fetch the details of a single node by ID.

ankra cluster ovh nodes list <cluster_id>
ankra cluster ovh nodes get <cluster_id> <node_id>

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/nodes \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/nodes/<node_id> \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

Deprovisioning

Deprovisioning deletes all OVH resources (instances, networks, SSH keys) and removes the cluster from Ankra.

This action is irreversible. All data on the cluster will be permanently deleted.

Via the Dashboard

Go to your cluster → Settings → General → Danger Zone and click Deprovision Cluster. You will be asked to confirm before the operation begins.

Via CLI or API

ankra cluster ovh deprovision <cluster_id>

curl -X DELETE https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id> \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"

Architecture

An OVH cluster provisions the following infrastructure:

Component	Description
Gateway	Jump server for secure SSH access to cluster nodes
Private Network	Isolated VLAN for inter-node communication
Control Plane(s)	Kubernetes control plane instances
Worker(s)	Kubernetes worker instances for running workloads
SSH Keys	Deployed to all instances for access

All nodes are deployed within a private OVH network. The gateway provides the only external SSH access point.

Troubleshooting

Common Issues

Issue	Solution
Cluster stuck in provisioning	Check OVH API credentials and project quota
Cannot scale workers	Ensure cluster is online and no operations are running
Invalid API credentials	Re-validate at OVH API Console
Flavor unavailable	Try a different region or flavor

OVH Cloud Quotas

OVH Cloud has default resource limits per project. If provisioning fails, check your quotas in the OVH Control Panel:

Instances
Networks / VLANs
SSH Keys

Contact OVH support to increase limits if needed.

​Prerequisites

OVH API Credential

SSH Key Credential

​Creating an OVH Cluster

​Via the Platform UI

​Managing from the Dashboard

​Via the CLI

​Via the API

​Node Groups

​Node Group API Reference

​Legacy Worker Scaling

​Upgrading Kubernetes Version

​Via the Dashboard

​Check Current Version

​Upgrade Version

​Stopping and Starting a Cluster

​SSH Access and Keys

​Managing the Control Plane

​Inspecting Nodes

​Deprovisioning

​Via the Dashboard

​Via CLI or API

​Architecture

​Troubleshooting

​Common Issues

​OVH Cloud Quotas

Prerequisites

Creating an OVH Cluster

Via the Platform UI

Managing from the Dashboard

Via the CLI

Via the API

Node Groups

Node Group API Reference

Legacy Worker Scaling

Upgrading Kubernetes Version

Via the Dashboard

Check Current Version

Upgrade Version

Stopping and Starting a Cluster

SSH Access and Keys

Managing the Control Plane

Inspecting Nodes

Deprovisioning

Via the Dashboard

Via CLI or API

Architecture

Troubleshooting

Common Issues

OVH Cloud Quotas