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

# OVH Clusters

> Create, manage, and scale Kubernetes clusters on OVH Cloud with Ankra.

Ankra supports provisioning fully managed Kubernetes clusters on [OVH Cloud](https://www.ovhcloud.com/). 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:

<CardGroup cols={2}>
  <Card title="OVH API Credential" icon="key">
    OVH Cloud API credentials (application key, application secret, consumer key, and project ID). See [OVH API Credentials](/integrations/credentials#ovh-api-credentials).
  </Card>

  <Card title="SSH Key Credential" icon="lock">
    An SSH public key for server access. You can provide your own or let Ankra generate one. See [SSH Key Credentials](/integrations/credentials#ssh-key-credentials).
  </Card>
</CardGroup>

***

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

<Steps>
  <Step title="Navigate to Clusters">
    Go to **Clusters** in the Ankra dashboard and click **Create Cluster**.
  </Step>

  <Step title="Select OVH Cloud">
    Choose **OVH Cloud** as the provider.
  </Step>

  <Step title="Select Credentials">
    Pick your OVH API credential and SSH key credential from the dropdowns. You can also create new credentials directly from the wizard.
  </Step>

  <Step title="Choose Region">
    Select an OVH Cloud region (e.g., Gravelines, Strasbourg, Beauharnois, Warsaw, London, Frankfurt). Each region shows the location and country.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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**.
  </Step>
</Steps>

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

```bash theme={null}
# 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

```bash theme={null}
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](/reference/ovh).

***

## 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](/reference/ovh#node-group-api-reference).

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:

```bash theme={null}
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](/guides/hetzner-clusters#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.

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh workers <cluster_id>
  ankra cluster ovh scale <cluster_id> 4
  ```

  ```bash cURL theme={null}
  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}'
  ```
</CodeGroup>

<Note>
  For new clusters, prefer using [Node Groups](#node-groups) for more granular control.
</Note>

***

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

<Warning>
  * 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.
</Warning>

### Via the Dashboard

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

### Check Current Version

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh k8s-version <cluster_id>
  ```

  ```bash cURL theme={null}
  curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/k8s-version \
    -H "Authorization: Bearer $ANKRA_API_TOKEN"
  ```
</CodeGroup>

Response:

```json theme={null}
{
  "current_version": "v1.34.4+k3s1",
  "distribution": "k3s"
}
```

### Upgrade Version

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh upgrade <cluster_id> v1.35.1+k3s1
  ```

  ```bash cURL theme={null}
  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"}'
  ```
</CodeGroup>

Response:

```json theme={null}
{
  "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.

<CodeGroup>
  ```bash CLI theme={null}
  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
  ```

  ```bash cURL theme={null}
  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"
  ```
</CodeGroup>

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

***

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

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh access-info <cluster_id>
  ```

  ```bash cURL theme={null}
  curl https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id>/access-info \
    -H "Authorization: Bearer $ANKRA_API_TOKEN"
  ```
</CodeGroup>

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

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh ssh-keys get <cluster_id>
  ankra cluster ovh ssh-keys set <cluster_id> --ssh-key-credential-ids <id>,<id>
  ```

  ```bash cURL theme={null}
  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>"]}'
  ```
</CodeGroup>

***

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

<CodeGroup>
  ```bash CLI theme={null}
  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
  ```

  ```bash cURL theme={null}
  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"}'
  ```
</CodeGroup>

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

***

## Inspecting Nodes

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

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh nodes list <cluster_id>
  ankra cluster ovh nodes get <cluster_id> <node_id>
  ```

  ```bash cURL theme={null}
  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"
  ```
</CodeGroup>

***

## Deprovisioning

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

<Warning>
  This action is irreversible. All data on the cluster will be permanently deleted.
</Warning>

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

<CodeGroup>
  ```bash CLI theme={null}
  ankra cluster ovh deprovision <cluster_id>
  ```

  ```bash cURL theme={null}
  curl -X DELETE https://platform.ankra.app/api/v1/clusters/ovh/<cluster_id> \
    -H "Authorization: Bearer $ANKRA_API_TOKEN"
  ```
</CodeGroup>

***

## 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](https://api.ovh.com/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](https://www.ovh.com/manager/):

* Instances
* Networks / VLANs
* SSH Keys

Contact OVH support to increase limits if needed.