Skip to content

AKS Platform

Some workloads need Kubernetes: containerised applications that scale, roll out and recover on their own. The AKS Platform is a solution that gives a platform team a fixed, repeatable foundation for such clusters: the cluster itself, its network, identities and access, security policy and secrets, all as Terraform. Workload teams get namespaces on that cluster with a predictable contract (access through groups, workload identity instead of stored credentials, default network and pod security rules).

The solution has two variants: AKS in Azure, and AKS on Azure Local (the Kubernetes cluster runs on hardware in your own data centre and is managed through Azure Arc). Both use the same layout and the same identity and secrets model.

Reference design, set per platform

The AKS Platform is not part of the core MCP hub and spoke. Whether it is available, which variant you get and which options are switched on depends on your platform. The names, sizes and schedules on these pages are the values of the reference configuration; your deployment may differ. The platform team is XMMS under a managed-service contract, or your own team when you self-manage (Operating models).

Status of the sources

These pages are built from the solution's Terraform code, pipelines and design documents. Where the design documents and the Terraform code disagree, the pages state what the code does and say so. The in-cluster platform services (GitOps controller, ingress gateway, monitoring, policy engine) are deployed from separate GitOps repositories that are not part of this documentation set. They are described here only as far as the design documents describe them.

Terminology

Term Meaning
Layer One Terraform module group of the solution: networking, identity, security policy, cluster baseline, secrets. Each layer has a deploy_* switch.
Cluster baseline The standard configuration of an AKS cluster: node pools, network profile, identity, add-ons, maintenance windows.
Environment nonprod or prod, plus nonprod-integrated and prod-integrated for clusters in a hub-integrated network. Each platform and environment has its own configuration file and its own Terraform state.
Platform azure (AKS in Azure) or azure-local (AKS on Azure Local).
Standalone / hub-integrated The two networking modes of the Azure variant: the solution builds its own spoke, or it uses a spoke from the hub and landing zone (Networking).
Bootstrap The one-time creation of an Azure Local cluster with the Azure CLI, before Terraform takes over (AKS on Azure Local).
GitOps repositories Separate repositories with the Kubernetes manifests (namespaces, RBAC, policies, platform services, applications) that Argo CD applies to the cluster.

What you get

Area What the solution does Page
Service description Scope, variants, boundaries and the split of responsibilities Service description
Using the cluster Namespaces, access groups, workload identity, ingress and Key Vault from a workload team's view Using the cluster
Security policy Admission rules, network policies, quotas and exceptions Security policy
Architecture Layers, environments, resource groups and how the pieces connect Architecture
Cluster baseline Node pools, upgrades, add-ons, identities of the cluster Cluster baseline
Networking Spoke layout, egress, DNS, private endpoints, hub integration Networking
Identity and access Entra ID groups, Azure and Kubernetes RBAC, CI/CD identities, secrets Identity and access
Azure Local What differs on AKS on Azure Local and what is not managed AKS on Azure Local
Prerequisites What must exist before a deployment, per variant Prerequisites
Deployment Pipelines, configuration files, roles of the pipeline identity Deployment
Operations Upgrades, start and stop, alerting and on-call, known gaps Operations
Load testing How the platform is load tested and what is measured Load testing
Decisions The main design decisions in short form Decisions

Variants at a glance

AKS in Azure AKS on Azure Local
Cluster resource Terraform (azurerm_kubernetes_cluster) Azure CLI bootstrap (az aksarc create), then Arc extensions with Terraform
Where nodes run Azure Azure Local hardware in your data centre
Network VNet and subnets, built by the solution or provided by the hub Existing Azure Local logical network
Egress and DNS Route table or hub firewall, Private DNS zones Your physical network
Load balancing Azure load balancer MetalLB, enabled through Azure Arc
Policy Azure Policy add-on, plus Kyverno from GitOps Azure Policy extension for Arc, plus Kyverno from GitOps
Secrets and identity Key Vault, workload identity Key Vault, workload identity

The Azure Local variant is newer and less complete. See AKS on Azure Local for what is and is not automated.

Responsibilities

Platform team Workload team
Terraform layers, cluster baseline, upgrades Yes
Entra ID groups and Azure role assignments Yes Requests
Namespaces, quotas, RBAC bindings, policies Yes (through the GitOps repository) Requests
Platform services (ingress gateway, monitoring, certificates) Yes
Routes, application deployments, application network rules Yes
Container images and what the application does with its secrets Yes

The full table is on Service description. The generic split is on Responsibilities.