|
| 1 | +--- |
| 2 | +title: Availability zones in Azure Kubernetes Service (AKS) overview |
| 3 | +description: Learn about using availability zones in Azure Kubernetes Service (AKS) to increase the availability of your applications. |
| 4 | +ms.service: azure-kubernetes-service |
| 5 | +ms.topic: article |
| 6 | +ms.date: 04/24/2024 |
| 7 | +author: schaffererin |
| 8 | +ms.author: schaffererin |
| 9 | +--- |
| 10 | + |
| 11 | +# Availability zones in Azure Kubernetes Service (AKS) overview |
| 12 | + |
| 13 | +This article provides an overview of using availability zones in Azure Kubernetes Service (AKS) to increase the availability of your applications. |
| 14 | + |
| 15 | +An AKS cluster distributes resources, such as nodes and storage, across logical sections of underlying Azure infrastructure. Using availability zones physically separates nodes from other nodes deployed to different availability zones. AKS clusters deployed with multiple availability zones configured across a cluster provide a higher level of availability to protect against a hardware failure or a planned maintenance event. |
| 16 | + |
| 17 | +## What are availability zones? |
| 18 | + |
| 19 | +Availability zones help protect your applications and data from datacenter failures. Zones are unique physical locations within an Azure region. Each zone includes one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there's always more than one zone in all zone enabled regions. The physical separation of availability zones within a region protects applications and data from datacenter failures. |
| 20 | + |
| 21 | +AKS clusters deployed using availability zones can distribute nodes across multiple zones within a single region. For example, a cluster in the *East US 2* region can create nodes in all three availability zones in *East US 2*. This distribution of AKS cluster resources improves cluster availability as they're resilient to failure of a specific zone. |
| 22 | + |
| 23 | + |
| 24 | + |
| 25 | +If a single zone becomes unavailable, your applications continue to run on clusters configured to spread across multiple zones. |
| 26 | + |
| 27 | +For more information, see [Using Azure availability zones](../reliability/availability-zones-overview.md). |
| 28 | + |
| 29 | +> [!NOTE] |
| 30 | +> When implementing **availability zones with the [cluster autoscaler](./cluster-autoscaler-overview.md)**, we recommend using a single node pool for each zone. You can set the `--balance-similar-node-groups` parameter to `true` to maintain a balanced distribution of nodes across zones for your workloads during scale up operations. When this approach isn't implemented, scale down operations can disrupt the balance of nodes across zones. This configuration doesn't guarantee that similar node groups will have the same number of nodes: |
| 31 | +> |
| 32 | +> * Currently, balancing happens during scale up operations only. The cluster autoscaler scales down underutilized nodes regardless of the relative sizes of the node groups. |
| 33 | +> * The cluster autoscaler only adds as many nodes as required to run all existing pods. Some groups might have more nodes than others if they have more pods scheduled. |
| 34 | +> * The cluster autoscaler only balances between node groups that can support the same set of pending pods. |
| 35 | +> |
| 36 | +> You can also use Azure zone-redundant storage (ZRS) disks to replicate your storage across three availability zones in the region you select. A ZRS disk lets you recover from availability zone failure without data loss. For more information, see [ZRS for managed disks](../virtual-machines/disks-redundancy.md#zone-redundant-storage-for-managed-disks). |
| 37 | +
|
| 38 | +## Limitations |
| 39 | + |
| 40 | +The following limitations apply when you create an AKS cluster using availability zones: |
| 41 | + |
| 42 | +* You can only define availability zones during creation of the cluster or node pool. |
| 43 | +* It is not possible to update an existing non-availability zone cluster to use availability zones after creating the cluster. |
| 44 | +* The chosen node size (VM SKU) selected must be available across all availability zones selected. |
| 45 | +* Clusters with availability zones enabled require using Azure Standard Load Balancers for distribution across zones. You can only define this load balancer type at cluster create time. For more information and the limitations of the standard load balancer, see [Azure load balancer standard SKU limitations][standard-lb-limitations]. |
| 46 | + |
| 47 | +## Azure Disk availability zones support |
| 48 | + |
| 49 | +Volumes that use Azure managed LRS disks aren't zone-redundant resources, and attaching across zones isn't supported. You need to colocate volumes in the same zone as the specified node hosting the target pod. Volumes that use Azure managed ZRS disks are zone-redundant resources. You can schedule those volumes on all zone and non-zone agent nodes. The following example shows how to create a storage class using the *StandardSSD_ZRS* disk: |
| 50 | + |
| 51 | +```yaml |
| 52 | +apiVersion: storage.k8s.io/v1 |
| 53 | +kind: StorageClass |
| 54 | +metadata: |
| 55 | + name: managed-csi-zrs |
| 56 | +provisioner: disk.csi.azure.com |
| 57 | +parameters: |
| 58 | + skuName: StandardSSD_ZRS # or Premium_ZRS |
| 59 | +reclaimPolicy: Delete |
| 60 | +volumeBindingMode: WaitForFirstConsumer |
| 61 | +allowVolumeExpansion: true |
| 62 | +``` |
| 63 | +
|
| 64 | +Kubernetes versions 1.12 and higher are aware of Azure availability zones. You can deploy a PersistentVolumeClaim object referencing an Azure Managed Disk in a multi-zone AKS cluster and [Kubernetes takes care of scheduling](https://kubernetes.io/docs/setup/best-practices/multiple-zones/#storage-access-for-zones) any pod that claims this PVC in the correct availability zone. |
| 65 | +
|
| 66 | +## Next steps |
| 67 | +
|
| 68 | +* [Create an AKS cluster with availability zones](./availability-zones.md). |
| 69 | +
|
| 70 | +<!-- LINKS --> |
| 71 | +[standard-lb-limitations]: load-balancer-standard.md#limitations |
0 commit comments