Conjuntos de disponibilidade no AKS habilitados pelo Azure Arc
Os conjuntos de disponibilidade são grupos lógicos de VMs que têm relações de antiafinidade fracas entre si, para garantir que sejam distribuídos uniformemente pelos domínios de falha disponíveis em um cluster físico. Um domínio de falha neste contexto é um host físico ou um grupo de hosts físicos. Usando conjuntos de disponibilidade, o AKS Arc pode melhorar a disponibilidade e a distribuição de suas cargas de trabalho do Kubernetes. Os conjuntos de disponibilidade podem evitar cenários em que uma falha de um único nó pode fazer com que várias VMs fiquem inativas ou desequilibradas.
Descrição geral
Os conjuntos de disponibilidade oferecem vários benefícios para o AKS em usuários do Azure Local, como:
- Melhora a disponibilidade e a resiliência de seus aplicativos, evitando cenários em que várias VMs dentro do mesmo pool de nós ou plano de controle ficam inativas ou desequilibradas devido a uma falha de um único nó.
- Otimiza o uso de recursos e o desempenho do cluster, garantindo que as VMs sejam distribuídas uniformemente entre os nós disponíveis e não concentradas em um único nó ou subconjunto de nós.
- Alinha-se com as melhores práticas e expectativas de seus clientes e parceiros que procuram uma experiência Kubernetes local confiável e consistente.
Ativar conjuntos de disponibilidade
Com o AKS no Azure Local, versão 23H2, o recurso de conjuntos de disponibilidade é habilitado por padrão quando você cria um pool de nós. Com o AKS no Windows Server, você pode habilitar o recurso de conjuntos de disponibilidade adicionando o -enableAvailabilitySet parâmetro ao criar um cluster AKS, por exemplo, New-AksHciCluster -Name <name> -controlPlaneNodeCount 3 -osType Linux -kubernetesVersion $kubernetesVersion -enableAvailabilitySet.
Como funcionam os conjuntos de disponibilidade no AKS habilitado pelo Azure Arc
Quando você cria um novo cluster AKS Arc, o AKS Arc cria automaticamente conjuntos de disponibilidade, um para as VMs do plano de controle e outro para cada um dos pools de nós no cluster Kubernetes. Cada pool de nós tem seu próprio conjunto de disponibilidade. Com esse layout, o AKS Arc garante que VMs da mesma função (plano de controle ou pool de nós) nunca estejam localizadas no mesmo host físico e que sejam distribuídas entre os nós disponíveis em um cluster.
Depois que os conjuntos de disponibilidade são criados e as VMs atribuídas, o sistema os coloca automaticamente nos nós físicos apropriados. Se um nó falhar, o sistema também fará failover automático das VMs para outros nós e as reequilibrará quando o nó se recuperar. Dessa forma, você pode obter alta disponibilidade e distribuição ideal de suas cargas de trabalho do Kubernetes sem intervenção manual.
Considere um AKS no Azure Local, cluster de versão 23H2 com duas máquinas host físicas, Host A e Host B, três VMs de plano de controle e duas VMs de nó de trabalho, Nodepool1VM1 e Nodepool1VM2. Para garantir a alta disponibilidade de seus aplicativos Kubernetes, as VMs do pool de nós nunca devem compartilhar o mesmo host, a menos que um dos hosts esteja temporariamente indisponível para manutenção planejada ou problema de capacidade, o que pode fazer com que a VM (máquina virtual) seja temporariamente colocada em um host alternativo.
No diagrama a seguir, cada cor representa um grupo de antiafinidade:
Se o Host B ficar inativo devido a uma reinicialização, o Plano de Controle VM2, o Plano de Controle VM3 e o Nodepool1VM2 farão failover para o Host A, conforme mostrado na figura a seguir. Supondo que seu aplicativo esteja executando pods no NodePoolVM1, essa reinicialização não tem impacto no seu aplicativo:
Na arquitetura antiga, se o Host B voltasse a ficar online após uma reinicialização, não havia garantia de que as VMs voltariam do Host A para o Host B (reequilíbrio), forçando assim as cargas de trabalho a permanecerem no mesmo host e criariam um único ponto de falha, conforme mostrado no diagrama a seguir:
Os conjuntos de disponibilidade para o AKS Arc podem ajudar a reequilibrar as VMs assim que um host se recuperar de uma interrupção temporária. Neste exemplo, ControlPlaneVM2, ControlPlaneVM3 e Nodepool1VM2 são movidos automaticamente para o Host B, conforme mostrado aqui:
Importante
Os conjuntos de disponibilidade no AKS Arc são um novo recurso que ainda está evoluindo e melhorando. Ainda não suportamos a configuração manual dos domínios de falha ou conjuntos de disponibilidade. Não é possível alterar os domínios de falha de um conjunto de disponibilidade depois que ele é criado. As VMs são atribuídas a um conjunto de disponibilidade na criação do cluster e não podem ser migradas para um conjunto de disponibilidade diferente.
Adicionar ou excluir máquinas
Em um cenário de exclusão de host, o host não é mais considerado parte do cluster. Essa exclusão normalmente ocorre quando você substitui uma máquina devido a problemas de hardware ou reduz o cluster Local do Azure por outros motivos. Durante uma interrupção de nó, o nó permanece parte do cluster Local do Azure, mas aparece como Inativo.
Se uma máquina física (domínio de falha) for excluída permanentemente do cluster, a configuração do conjunto de disponibilidade não será modificada para reduzir o número de domínios de falha. Nesse cenário, o conjunto de disponibilidade entra em um estado não íntegro. Recomendamos que você reimplante seus clusters Kubernetes para que o conjunto de disponibilidade seja atualizado com o número adequado de domínios de falha.
Quando uma nova máquina física (domínio de falha) é adicionada ao cluster, a configuração do conjunto de disponibilidade é automaticamente expandida para incluir a nova máquina. No entanto, as VMs existentes não se reequilibram para aplicar essa nova configuração, pois já estão atribuídas a conjuntos de disponibilidade. Recomendamos que você reimplante seus clusters Kubernetes para que o conjunto de disponibilidade seja atualizado com o número adequado de domínios de falha.