Skip to main content
You manage your infrastructure with Terraform and want Ankra clusters in the same plan. The Ankra Terraform provider, ankraio/ankra on the Terraform Registry, lets Terraform create clusters on your cloud through Ankra, or register a cluster you already run together with its Stacks. This page describes provider 0.2.1, the latest release. The Registry carries the generated reference for every attribute.
Upgrading from 0.1.x? Read Upgrade from 0.1.x first: two default values changed in a way that can replace a cluster.

Configure the provider

The provider needs Terraform 1.0 or newer (it is tested with 1.6 to 1.12).
If no token reaches a resource, from the provider or the deprecated per-resource ankra_token, Terraform stops with Missing API token and sends no request.

Resources and data sources

Managed Kubernetes (DOKS, UKS, GKE, AKS, EKS and the others) and the AWS, Proxmox, Morpheus and Ankra Cloud providers have no Terraform resource yet. Create those with the Ankra CLI or the UI.

Create a cluster on your cloud

The five cloud resources share most arguments and each keeps its cloud’s own words for size and place: server_type and location on Hetzner, size and region on DigitalOcean, flavor_id and region on OVHcloud, plan and zone on UpCloud, type, region and zone on Scaleway.
Arguments every cloud resource takes: Every provisioning argument forces replacement: change a node count or size in Terraform and the plan destroys and recreates the cluster. Scale and resize an existing cluster with the CLI or the UI instead, and see Known limits. terraform destroy asks Ankra to deprovision the cluster and remove what it created in your cloud account. With force_destroy = true (the default) the platform skips its usual guards; set it to false to take the guarded delete path. Changing force_destroy never replaces the cluster.
Closed beta. Scaleway as a cluster provider is in closed beta, and ankra_scaleway_cluster only works for organisations that have it turned on. Until it is, the Scaleway endpoints are not served and the create fails. Contact support to have it turned on for your organisation.
Find the IDs with the CLI. The ID column of ankra credentials list holds credential_id, and the provider’s ssh-key list holds ssh_key_credential_id:

Register a cluster you already run

ankra_cluster registers a cluster you operate yourself, the same way an ImportCluster file does, and keeps its Stacks in Terraform.
How the Stack fields work:
  • parents orders deployment. Write each entry as "manifest:<name>" or "addon:<name>". A bare "<name>" works when exactly one manifest or add-on of that name is declared in the resource. Leaving parents out keeps the order already stored in Ankra; an empty list removes it.
  • registry_url is the Helm repository that serves the chart (https://... or oci://...). registry_name is the name of that Helm registry in your organisation. If you leave it out, the provider derives a name from the URL, which Ankra accepts when a registry with that URL is already connected; otherwise Ankra asks you to connect the registry first. Set registry_credential_name for a private registry.
  • configuration holds the Helm values, as YAML or base64-encoded YAML.
  • job_configuration is a JSON object of timeouts in seconds: create_job_timeout, read_job_timeout, update_job_timeout and delete_job_timeout. Build it with jsonencode.
The provider checks parents and job_configuration at plan time. If Ankra refuses the Stack, the error names the member and the field. Run helm_command against the cluster to connect it. Terraform cannot do that for you; a remote-exec provisioner on a host that can reach the cluster is one way:
If a cluster with the same cluster_name already exists, creating the resource adopts it: Ankra updates that cluster with your configuration and Terraform manages it from then on. Because the agent command is only issued on first registration, helm_command is empty for an adopted cluster, and Terraform prints a warning saying so. Copy the command from the Ankra UI if you need it. terraform destroy deletes the cluster from Ankra.

List clusters

Each entry has id and name.

Import existing clusters

Every resource imports by Ankra cluster ID:
After the import, write a configuration that matches the cluster and run terraform plan. On the cloud resources a mismatch in any provisioning argument plans a replacement, so check the plan before you apply.

Readiness and timeouts

Keep the wait on when anything in the same plan uses the cluster, such as a kubeconfig, a kubernetes provider or a module, because provisioning runs in the background. The cluster ID is saved to state before the wait starts, so a timeout reports how far the cluster got without losing track of it. Every read refreshes state and kind, so a cluster stopped or deleted outside Terraform shows up in the next plan. A cluster deleted outside Terraform is removed from state.

Known limits

  • Changing github_repository or github_branch on an existing ankra_cluster fails with a 409 error. Ankra refuses to move a cluster to a different GitOps source until the move is acknowledged, and the provider has no argument for that yet. Make the move outside Terraform as described under spec.git_repository in the ImportCluster reference, then update your configuration to match.
  • helm_command is empty for an adopted cluster, and when Ankra queued the import instead of running it.
  • Resizes made outside Terraform are not detected. Ankra’s cluster listing does not include node counts or sizes, so a plan cannot see them.
  • No managed Kubernetes and no node groups. See Resources and data sources.
Keep each cluster managed from one place, so Terraform, the CLI and the UI do not overwrite each other’s changes.

Upgrade from 0.1.x

0.1.6 cannot create or update a cluster against the current Ankra API, so upgrade before you use the provider. Upgrade to 0.2.1 rather than 0.2.0: 0.2.0 refuses a configuration that sets the token only on each resource, which is how 0.1.x was configured. Before you run terraform init -upgrade:
  1. Pin distribution and cni on cloud resources. Both now default to kubeadm and cilium, and both force replacement. If a cluster was created with the old k3s and flannel defaults, add distribution = "k3s" and cni = "flannel" first, or the next plan replaces it.
  2. Use Terraform 1.0 or newer. The provider now runs on Terraform plugin protocol 6.
  3. Move the token to the provider. Set token on the provider block or ANKRA_TOKEN. The per-resource ankra_token still works but is deprecated, and changing it no longer replaces the cluster.
  4. Update add-ons. Replace repository_url with registry_url (the old name still works) and add registry_name. Write job_configuration as jsonencode({ ... }). configuration_type is ignored.
  5. Update parents. Use "manifest:<name>" or "addon:<name>", or a bare name that matches exactly one member of the resource.
  6. Rotate agent tokens printed by 0.1.x. helm_command contains a live agent token and 0.1.x did not mark it sensitive. If a plan or CI log printed it, rotate that token.
Then run terraform plan and check it reports no replacement you did not expect. The full list of changes is in the provider’s changelog.

Next steps

Create an API token, store your cloud credential, and add the provider block above to your configuration.