--- title: "Multi-cluster DNS-based load balancing with Azure Kubernetes Fleet Manager" description: Understand how Fleet Manager supports DNS-based load balancing for placed workloads. ms.date: 05/14/2026 author: sjwaight ms.author: simonwaight ms.service: azure-kubernetes-fleet-manager ms.topic: concept-article # Customer intent: As a cloud administrator, I want to set up DNS-based load balancing across multiple Kubernetes clusters using Fleet Manager, so that I can efficiently manage traffic distribution for public-facing workloads. --- # Multi-cluster DNS-based load balancing with Azure Kubernetes Fleet Manager (preview) **Applies to**: :heavy_check_mark: Fleet Manager with hub cluster Azure Kubernetes Fleet Manager can be used to create and manage DNS-based multi-cluster load balancing for public-facing workloads deployed across member clusters. [!INCLUDE [preview features note](./includes/preview/preview-callout-data-plane-network.md)] :::image type="content" source="./media/concepts-dns-load-balancing/fleet-dns-load-balance-conceptual.png" alt-text="A diagram showing a conceptual overview of how Fleet Manager supports DNS load balancing across three member clusters using Azure Traffic Manager and Kubernetes ServiceExport resources." lightbox="./media/concepts-dns-load-balancing/fleet-dns-load-balance-conceptual.png"::: To deliver multi-cluster public load balancing with DNS, Fleet Manager utilizes [Azure Traffic Manager][traffic-manager-overview] with a [weighted routing profile][traffic-manager-weighted] to act as a frontend for `Services` exported from member clusters. It is possible to use this capability for both layer 4 and 7 load balancing. Fleet administrators use `kubectl` to create and configure `TrafficManagerProfile` and `TrafficManagerBackend` resources on the Fleet Manager hub cluster. The `TrafficManagerProfile` defines an Azure Traffic Manager Profile that includes [endpoint health monitoring][traffic-manager-health-check] configuration, with the associated `TrafficManagerBackend` defining the `Service` to be load balanced. Services on member clusters can be added to the load balancing by creating a `ServiceExport` on the cluster and configuring a unique DNS hostname for the `Service`. Optional weights can be defined that configure traffic routing behavior between clusters. If the workload is deployed using Fleet Manager's [cluster resource placement][concept-crp], the DNS hostname can be configured on placement using a `ResourceOverride`. The creation and configuration of the associated Traffic Manager is managed by Fleet Manager, with fleet administrators able to drive the end to end experience using the Kubernetes API. ## TrafficManagerProfile properties The `TrafficManagerProfile` resource provides a Kubernetes object representation of a standard Azure Traffic Manager Profile. ```yml apiVersion: networking.fleet.azure.com/v1beta1 kind: TrafficManagerProfile metadata: name: myatm namespace: work spec: monitorConfig: protocol: HTTP path: /api port: 8080 intervalInSeconds: 30 timeoutInSeconds: 10 toleratedNumberOfFailures: 3 ``` The important properties to understand include: * `name`: used as the DNS prefix for the `trafficmanager.net` DNS name. It must be unique. If the name is already in use, deployment fails. * `namespace`: must be the same as the corresponding `TrafficManagerBackend` and `Service` resources. * `monitorCOnfig`: maps to the standard Azure Traffic Manager monitoring configuration. Unsupported Azure Traffic Manager endpoint monitoring options are: Custom header settings; expected status codes. ## TrafficManagerBackend properties The `TrafficManagerBackend` resource provides a Kubernetes object that is used to store backend endpoints which can be considered by Traffic Manager to receive traffic. Before traffic is routed to an endpoint a `ServiceExport` must be created. ```yml apiVersion: networking.fleet.azure.com/v1beta1 kind: TrafficManagerBackend metadata: name: app namespace: work spec: profile: name: myatm backend: name: app weight: 100 ``` The important properties to understand include: * `spec/profile/name`: must match the corresponding `TrafficManagerProfile`. * `spec/backend/name`: must match the exported service name to load balance. * `spec/weight`: optional weight (priority) to apply to this backend. Integer value between 0 and 1,000. If omitted, Traffic Manager uses a default weight of '1'. Set to '0' to disable traffic routing without deleting the associated Traffic Manger Profile resource. For further information, see [Azure Traffic Manager weighted routing method][traffic-manager-weighted]. ## ServiceExport properties To add an endpoint for a `Service` to Traffic Manager, create a `ServiceExport` resource on the member cluster containing the service. The `ServiceExport` resource must be created in the same namespace as the `Service` to be exported. ```yml apiVersion: networking.fleet.azure.com/v1alpha1 kind: ServiceExport metadata: name: kuard-export namespace: kuard-demo annotations: networking.fleet.azure.com/weight: "50" ``` The important properties to understand include: * `metadata/namespace`: must match the namespace of the `Service` to be exported. * `metadata/annotations/networking.fleet.azure.com/weight`: optional weight (priority) to apply to this service export. Integer value between 0 and 1,000. If omitted, Traffic Manager uses a default weight of '1'. Set to '0' to disable traffic routing without deleting the associated Service endpoint. For further information, see [Azure Traffic Manager weighted routing method][traffic-manager-weighted]. ## Unique DNS hostname via Service annotation In order to add a `Service` to the Traffic Manager, it must have a unique DNS hostname. The DNS hostname can be set by following the AKS recommended method of using the `service.beta.kubernetes.io/azure-dns-label-name` annotation as shown. ```yml apiVersion: v1 kind: Service metadata: name: kuard-svc namespace: kuard-demo labels: app: kuard annotations: service.beta.kubernetes.io/azure-dns-label-name: kuard-demo-cluster-01 spec: selector: app: kuard ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer ``` The DNS label annotation can be overridden using the `ResourceOverride` feature of Fleet Manager making it possible to deploy unique host names across multiple clusters. For further information, see the [DNS load balancing how-to guide](./howto-dns-load-balancing.md). ## Controlling traffic routing In this section we look at common scenarios for controlling traffic routing between clusters. ### Distribute traffic across clusters To allow Traffic Manager to consider any cluster to receive traffic use the definitions shown. 1. Create a `TrafficManagerBackend` resource and omit the `weight` property. ```yml apiVersion: networking.fleet.azure.com/v1beta1 kind: TrafficManagerBackend metadata: name: app namespace: work spec: profile: name: myatm backend: name: app ``` 1. On each cluster, create a `ServiceExport` and omit the `weight` property. ```yml apiVersion: networking.fleet.azure.com/v1alpha1 kind: ServiceExport metadata: name: kuard-export namespace: kuard-demo ``` Once deployed, Traffic Manager will pick a cluster at random, considering all clusters of equal weight. ### Distribute traffic across clusters with different weights To provide Traffic Manager with preference hints when selecting clusters, set the `weight` property on the `TrafficManagerBackend` and `ServiceExport` objects. 1. Create a `TrafficManagerBackend` resource and set the `weight` property to `100`. ```yml apiVersion: networking.fleet.azure.com/v1beta1 kind: TrafficManagerBackend metadata: name: app namespace: work spec: profile: name: myatm backend: name: app weight: 100 ``` 1. Create a `ServiceExport` and set the `weight` property to a value representing the priority Traffic Manager should use when considering a cluster to receive traffic. ```yml apiVersion: networking.fleet.azure.com/v1alpha1 kind: ServiceExport metadata: name: kuard-export namespace: kuard-demo annotations: networking.fleet.azure.com/weight: "40" ``` Once deployed, Traffic Manager will preference clusters with a higher weight. It is not required that you set the weight value on every cluster. If you set the weight value the same on more than one cluster, Traffic Manager will consider those clusters equally. ### Exclude a cluster from traffic routing To exclude a cluster from traffic routing, set the `weight` property to `0` on the `ServiceExport` resource. This weight removes the endpoint from the Traffic Manager configuration. ```yml apiVersion: networking.fleet.azure.com/v1alpha1 kind: ServiceExport metadata: name: kuard-export namespace: kuard-demo annotations: networking.fleet.azure.com/weight: "0" ``` ## TrafficManagerProfile deletion behavior When a `TrafficManagerProfile` Kubernetes resource is deleted, the associated Azure Traffic Manager and its endpoints are also deleted and requests are no longer routed to clusters. If you wish to stop traffic routing but retain the Azure Traffic Manager and its endpoints, set the `weight` property to `0` on the `TrafficManagerBackend` resource. ## Next steps * [Set up DNS load balancing across Azure Kubernetes Fleet Manager member clusters](./howto-dns-load-balancing.md). * [Hands-on exercise on GitHub for this feature](https://github.com/Azure/fleet-networking/tree/main/docs/demos/TrafficManagerProfile). [traffic-manager-overview]: /azure/traffic-manager/traffic-manager-overview [traffic-manager-weighted]: /azure/traffic-manager/traffic-manager-routing-methods#weighted-traffic-routing-method [traffic-manager-health-check]: /azure/traffic-manager/traffic-manager-monitoring#configure-endpoint-monitoring [concept-crp]: ./concepts-resource-placement.md