Clusters multiply for good reasons, regions, blast radius, tenancy, regulatory boundaries, and suddenly the platform team runs twelve of them, each needing the same upgrades, the same baseline workloads, and coordinated rollouts. Azure Kubernetes Fleet Manager is the control plane for that problem, and today closes the multi cluster gap in this series.

Why Fleets Happen and What the Hub Does

A fleet resource groups member clusters (optionally with a managed hub cluster for the placement features) and gives you fleet wide machinery for the two chores that scale worst by hand: upgrades and workload distribution. Membership is just joining existing AKS clusters, nothing about them changes, and the fleet becomes the place where “all production clusters” is an addressable thing rather than a wiki list. The design point to respect: the fleet is a coordination plane, not a super cluster, applications still deploy to clusters, identities and networking remain per cluster from the earlier posts, and the GitOps repos from this week remain the source of truth, with the fleet orchestrating across them.

Update Runs: Upgrades as a Staged Pipeline

The killer feature. An update run applies a Kubernetes version or node image update across the fleet in stages you define: groups of clusters (staging first, then region by region), with wait periods between stages and approval gates where humans belong. The strategy encodes the rollout discipline the single cluster upgrade post preached, now fleet wide: canary on the staging group, soak, then production groups in sequence, halting automatically if a cluster’s update fails. Auto upgrade profiles extend it to continuous mode, new patch versions flow through the staged strategy without a human initiating, which pairs with the maintenance windows from the original post so the fleet patches itself in order, on schedule, with stops. For a twelve cluster estate this replaces a quarterly spreadsheet project with a resource definition, and the honesty check is the same as ever: the staging group only protects you if its configuration genuinely matches production, which the GitOps structure guarantees and hand managed clusters never did.

resource "azurerm_kubernetes_fleet_update_strategy" "prod_rollout" {
  name                        = "staged-prod"
  kubernetes_fleet_manager_id = azurerm_kubernetes_fleet_manager.this.id

  stage {
    name = "staging"
    group { name = "staging-clusters" }
    after_stage_wait_in_seconds = 3600
  }

  stage {
    name = "prod-europe"
    group { name = "prod-weu" }
    after_stage_wait_in_seconds = 7200
  }

  stage {
    name = "prod-us"
    group { name = "prod-eus" }
  }
}

Placement and Multi Cluster Traffic

With the hub enabled, cluster resource placement propagates Kubernetes resources from hub to members by policy: PickAll for the baseline stack every cluster runs, PickN with affinities for “this workload runs in three clusters with these labels”, with rollout strategies and per cluster overrides for the differences that legitimately exist. It overlaps GitOps deliberately, and the working division is: GitOps owns what runs in a cluster, placement earns its keep when the decision is which clusters, capacity aware scheduling of workloads across a fleet, progressive multi cluster rollouts, evacuating a cluster for maintenance by shifting its placements. North south traffic across the fleet stays with the patterns already built, Front Door over regional ingresses from the September posts, with fleet aware layer 4 options for the east west cases that need them. Start with update runs, they pay immediately, add placement when a real multi cluster scheduling need arrives, and the twelve clusters become one platform with twelve availability zones of a different kind.

Cheers
Osama