Partilhar via


Visão geral das zonas de disponibilidade no Serviço Kubernetes do Azure (AKS)

Este artigo fornece uma visão geral do uso de zonas de disponibilidade no Serviço Kubernetes do Azure (AKS) para aumentar a disponibilidade de seus aplicativos.

Um cluster AKS distribui recursos, como nós e armazenamento, entre seções lógicas da infraestrutura subjacente do Azure. O uso de zonas de disponibilidade separa fisicamente os nós de outros nós implantados em zonas de disponibilidade diferentes. Os clusters 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 as zonas de disponibilidade?

As zonas de disponibilidade ajudam a proteger seus aplicativos e dados contra falhas no datacenter. As zonas são locais físicos exclusivos dentro de uma região do Azure. Cada zona inclui um ou mais datacenters equipados com alimentação, refrigeração 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 numa região protege as aplicações e os dados de falhas do datacenter.

Os clusters AKS implantados usando zonas de disponibilidade podem distribuir nós em várias zonas dentro de uma única região. Por exemplo, um cluster na região Leste 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 AKS melhora a disponibilidade do cluster, pois eles são resilientes a falhas de uma zona específica.

Diagrama que mostra a distribuição do nó AKS entre zonas de disponibilidade.

Se uma única zona ficar indisponível, seus aplicativos continuarão a ser executados em clusters configurados para se espalharem por várias zonas.

Para obter mais informações, consulte Usando zonas de disponibilidade do Azure.

Nota

Ao implementar zonas de disponibilidade com o autoscaler de cluster, recomendamos o uso de um único pool de nós para cada zona. Você pode definir o --balance-similar-node-groups parâmetro para true manter uma distribuição equilibrada de nós entre zonas para suas cargas de trabalho durante operações de expansão. Quando essa abordagem não é implementada, as operações de redução de escala podem interromper o equilíbrio de nós entre zonas. Essa configuração não garante que grupos de nós semelhantes terão o mesmo número de nós:

  • Atualmente, o balanceamento acontece apenas durante as operações de scale-up. O autoscaler de cluster reduz os nós subutilizados, independentemente dos tamanhos relativos dos grupos de nós.
  • O autoscaler de cluster adiciona apenas 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 autoscaler de cluster equilibra apenas entre grupos de nós que podem suportar o 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 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 indisponibilidade existente para usar zonas de disponibilidade após a criação do cluster.
  • O tamanho do nó escolhido (VM SKU) selecionado deve estar disponível em todas as zonas de disponibilidade selecionadas.
  • Os clusters com zonas de disponibilidade habilitadas exigem o uso dos Balanceadores de Carga Padrão do Azure para distribuição entre zonas. Você só pode definir esse tipo de balanceador de carga no momento da criação do cluster. Para obter mais informações e as limitações do balanceador de carga padrão, consulte Limitações de SKU padrão do balanceador de carga do Azure.

Suporte a zonas de disponibilidade do Azure Disk

Os volumes que usam discos LRS gerenciados pelo Azure não são recursos redundantes de zona, e a anexação entre zonas não é suportada. Você precisa colocalizar volumes na mesma zona que o nó especificado que hospeda o pod de destino. Os volumes que usam discos ZRS gerenciados do Azure 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. Você pode implantar um objeto PersistentVolumeClaim fazendo referência a um Disco Gerenciado do Azure em um cluster AKS de várias zonas e o Kubernetes cuida do agendamento de qualquer pod que reivindica esse PVC na zona de disponibilidade correta.

Em vigor a partir da versão 1.29 do Kubernetes, quando você implanta clusters do Serviço Kubernetes do Azure (AKS) em várias zonas de disponibilidade, o AKS agora utiliza o armazenamento com redundância de zona (ZRS) para criar discos gerenciados dentro de classes de armazenamento internas. O ZRS garante a replicação síncrona de seus discos gerenciados do Azure em várias zonas de disponibilidade do Azure na região escolhida. Essa estratégia de redundância aumenta a resiliência de seus aplicativos e protege seus dados contra falhas no datacenter.

No entanto, é importante observar que o armazenamento com redundância de zona (ZRS) tem um custo mais alto em comparação com o armazenamento com redundância local (LRS). Se a otimização de custos for uma prioridade, você poderá criar uma nova classe de armazenamento com o skuname parâmetro definido como LRS. Em seguida, você pode usar a nova classe de armazenamento em sua Reivindicação de Volume Persistente (PVC).

Próximos passos