Azure Kubernetes Service (AKS)

Provision, import, and operate Azure Kubernetes Service (AKS) clusters with Ankra - network plugins, SKU tiers, private clusters, node pools, upgrades, GitOps, and AI-assisted operations.

Azure Kubernetes Service (AKS) is Microsoft Azure’s managed Kubernetes service. Azure runs the control plane; Ankra provisions the cluster, then manages everything on top - node pools, Kubernetes upgrades, addons, stacks, GitOps, and AI-assisted operations.

This page covers AKS specifically. For the shared concepts across all managed providers - live options, discovery/import, and day-2 API patterns - see Managed Kubernetes.

Why AKS with Ankra

• Network plugin and SKU tier - choose azure or kubenet networking and the control-plane SKU tier that fits your uptime needs.
• Private clusters - provision a private API endpoint when required.
• Live pricing and options - locations, Kubernetes versions, and VM sizes are fetched live with your service principal, including spot and autoscaling where available.

Prerequisites

An Azure service principal stored in Ankra with Contributor on the target subscription. See Azure Credentials.

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

Creating an AKS cluster

Portal

1. Create Cluster

   Go to Clusters → Create Cluster and pick Azure’s Cloud Managed action.

2. Credential & Location

   Select the Azure credential and a location (for example westeurope). Locations load live from Azure.

3. Node Pools

   Define one or more worker pools: name, VM size (with live pricing), count, labels, and autoscaling bounds.

4. Kubernetes & Network

   Pick a Kubernetes version or keep the default, choose the network plugin (azure or kubenet), the SKU tier (Free, Standard, or Premium), and whether the cluster is private.

5. GitOps (optional) & Create

   Optionally connect a Git repository, then create. Ankra runs AKS preflight checks, provisions the cluster, retrieves the kubeconfig, and installs the Ankra Agent.

CLI

ankra cluster managed create \
  --provider aks \
  --name my-aks-cluster \
  --credential-id <azure-credential-id> \
  --location westeurope \
  --node-pool-name workers \
  --node-pool-size Standard_D2s_v5 \
  --node-pool-count 2

Network plugin, SKU tier, private-cluster, resource group, and node-pool autoscaling bounds are set from the portal or the API.

API

curl -X POST https://platform.ankra.app/org/clusters/managed/aks \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-aks-cluster",
    "credential_id": "<azure-credential-id>",
    "location": "westeurope",
    "kubernetes_version": "1.32.3",
    "node_pools": [
      {
        "name": "workers",
        "size": "Standard_D2s_v5",
        "count": 2,
        "autoscaling": {"enabled": true, "min_count": 2, "max_count": 5}
      }
    ],
    "aks": {"network_plugin": "azure", "sku_tier": "Standard"}
  }'

AKS options

Field	Description
aks.resource_group	Target resource group
aks.network_plugin	azure or kubenet
aks.private_cluster	Provision a private API endpoint
aks.sku_tier	Free, Standard, or Premium

AKS node-pool names are lowercase alphanumeric and at most 12 characters; cluster names are at most 63 characters.

Day-2 operations

Node pools, upgrades, and deletion work from the CLI, portal, or API. The CLI examples use --provider aks:

# scale a pool to a fixed count
ankra cluster managed node-pool scale <cluster_id> workers --provider aks --count 5

# upgrade the cluster
ankra cluster managed upgrade <cluster_id> --provider aks --version 1.32.3

# delete the cluster
ankra cluster managed delete <cluster_id> --provider aks

Autoscaling bounds are set with ankra cluster managed node-pool update <cluster_id> <pool> --provider aks --autoscaling --autoscaling-min 2 --autoscaling-max 8, from the portal, or via the PATCH .../node-pools/{name} endpoint. See Managed Kubernetes - day-2 operations for the shared mechanics.

Stopping and Starting

AKS is the only managed provider with native cluster stop/start, and Ankra exposes it in the portal Danger Zone, CLI, API, and Ankra AI/MCP. Stopping deallocates the control plane and agent pools (Azure stops billing for compute) while keeping all configuration, and starting brings the same cluster back.

In the portal, open Settings → General → Danger Zone and choose Stop cluster. When Azure finishes the operation, the same area offers Start cluster.

ankra cluster managed stop <cluster_id> --provider aks
ankra cluster managed start <cluster_id> --provider aks

The API exposes the same asynchronous stop and start operations. You can also ask Ankra’s AI or any MCP client to “stop my AKS cluster” or “start my AKS cluster”; write operations require confirmation.

Both operations are asynchronous on Azure’s side - the cluster shows stopped or running once Azure completes the transition. Other managed providers do not support stop/start; Ankra advertises the capability per provider as supports_stop_start.

Importing an existing AKS cluster

Already running AKS? Discover clusters in your subscription and adopt them into Ankra without touching them. Discovery and import run from the portal or API - see Managed Kubernetes - importing existing clusters.

Related

• Managed Kubernetes overview
• Azure Credentials
• Cluster settings