Visão geral das zonas de disponibilidade no AKS (Serviço de Kubernetes do Azure)
Este artigo fornece uma visão geral do uso de zonas de disponibilidade no AKS (Serviço de Kubernetes do Azure) para aumentar a disponibilidade de seus aplicativos.
Um cluster do AKS distribui recursos, como nós e armazenamento, entre seções lógicas da infraestrutura subjacente do Azure. O uso de zonas de disponibilidades separa fisicamente os nós de outros nós implantados em diferentes zonas de disponibilidade. Os clusters do AKS implantados com várias zonas de disponibilidade configuradas em um cluster fornecem um nível mais alto de disponibilidade para proteger contra uma falha de hardware ou um evento de manutenção planejada.
O que são zonas de disponibilidade?
As zonas de disponibilidade ajudam a proteger seus aplicativos e dados contra falhas de datacenter. As zonas são locais físicos exclusivos em uma região do Azure. Cada zona inclui um ou mais datacenters equipados com energia, resfriamento e rede independentes. Para garantir a resiliência, há sempre mais de uma zona em todas as regiões habilitadas para zona. A separação física das zonas de disponibilidade dentro de uma região protege os aplicativos e os dados contra falhas do datacenter.
Os clusters do AKS implantados usando zonas de disponibilidade podem distribuir nós entre várias zonas em uma única região. Por exemplo, um cluster na regiãoLeste dos EUA 2 pode criar nós em todas as três zonas de disponibilidade no Leste dos EUA 2. Essa distribuição de recursos de cluster do AKS melhora a disponibilidade do cluster, pois eles são resilientes à falha de uma zona específica.
Se uma única zona ficar indisponível, seus aplicativos continuarão a ser executados em clusters configurados para distribuição entre várias zonas.
Para obter mais informações, consulte Usando zonas de disponibilidade do Azure.
Observação
Ao implementar zonas de disponibilidade com o dimensionador automático de cluster, recomendamos usar um único pool de nós para cada zona. Você pode definir o parâmetro --balance-similar-node-groups
para true
para manter uma distribuição equilibrada de nós entre zonas para suas cargas de trabalho durante operações de escalonamento vertical. Quando essa abordagem não é implementada, as operações de redução horizontal podem interromper o equilíbrio de nós entre zonas. Essa configuração não garante que grupos de nós semelhantes tenham o mesmo número de nós:
- Atualmente, o balanceamento ocorre somente durante operações de expansão. O dimensionador automático de cluster reduz verticalmente os nós subutilizados, independentemente dos tamanhos relativos dos grupos de nós.
- O dimensionador automático de cluster só adiciona quantos nós forem necessários para executar todos os pods existentes. Alguns grupos podem ter mais nós do que outros se tiverem mais pods agendados.
- O dimensionador automático de cluster só se equilibra entre grupos de nós que podem dar suporte ao mesmo conjunto de pods pendentes.
Você também pode usar discos ZRS (armazenamento com redundância de zona) do Azure para replicar seu armazenamento em três zonas de disponibilidade na região selecionada. Um disco ZRS permite que você se recupere de uma falha na zona de disponibilidade sem perda de dados. Para obter mais informações, consulte ZRS para discos gerenciados.
Limitações
As seguintes limitações se aplicam quando você cria um cluster do AKS usando zonas de disponibilidade:
- Você só pode definir zonas de disponibilidade durante a criação do cluster ou pool de nós.
- Não é possível atualizar um cluster de zona de não disponibilidade existente para usar zonas de disponibilidade depois de criar o cluster.
- O tamanho do nó escolhido (SKU da VM) selecionado deve estar disponível em todas as zonas de disponibilidade selecionadas.
- Clusters com zonas de disponibilidade habilitadas exigem o uso do Azure Standard Load Balancer para distribuição entre zonas. Você só pode definir esse tipo de balanceador de carga no momento da criação do cluster. Para saber mais e ver as limitações do Standard Load Balancer, confira Limitações da SKU do Azure Load Balancer Standard.
Suporte a zonas de disponibilidade do Disco do Azure
Os volumes que usam discos LRS gerenciados pelo Azure não são recursos com redundância de zona e não há suporte para anexação entre zonas. Você precisa colocar volumes na mesma zona que o nó especificado que hospeda o pod de destino. Os volumes que usam os discos ZRS gerenciados do Azure não são recursos com redundância de zona. Você pode agendar esses volumes em todos os nós de agente de zona e não zona. O exemplo a seguir mostra como criar uma classe de armazenamento usando o disco StandardSSD_ZRS:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-csi-zrs
provisioner: disk.csi.azure.com
parameters:
skuName: StandardSSD_ZRS # or Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
As versões 1.12 e superiores do Kubernetes estão cientes das zonas de disponibilidade do Azure. É possível implantar um objeto PersistentVolumeClaim referenciando um Disco Gerenciado do Azure em um cluster do AKS de várias zonas e o Kubernetes cuida do agendamento de qualquer pod que declara esse PVC na zona de disponibilidade correta.
A partir do Kubernetes versão 1.29, ao implantar clusters do Serviço de Kubernetes do Azure (AKS) em várias zonas de disponibilidade, o AKS agora utilizar o armazenamento com redundância de zona (ZRS) para criar discos gerenciados em classes de armazenamento internas. O ZRS garante a replicação síncrona dos discos gerenciados do Azure em várias zonas de disponibilidade do Azure na região escolhida. Essa estratégia de redundância melhora a resiliência dos aplicativos e protege os dados contra falhas de datacenter.
No entanto, é importante observar que o ZRS (armazenamento com redundância de zona) tem um custo mais alto em comparação ao LRS (armazenamento com redundância local). Se a otimização de custo for uma prioridade, você poderá criar uma nova classe de armazenamento com o parâmetro skuname
definido como LRS. Em seguida, você poderá usar a nova classe de armazenamento na Declaração de Volume Persistente (PVC).
Próximas etapas
Azure Kubernetes Service