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 fracas de antiafinidade entre si, para garantir que sejam distribuídas uniformemente entre os domínios de falha disponíveis em um cluster físico. Um domínio de falha nesse 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 nó único pode fazer com que várias VMs fiquem inativas ou desbalanceadas.
Visão geral
Os conjuntos de disponibilidade oferecem vários benefícios para usuários do AKS no Azure Local, como:
- Melhora a disponibilidade e a resiliência de seus aplicativos, evitando cenários em que várias VMs no mesmo pool de nós ou plano de controle ficam inativas ou desequilibradas devido a uma falha de nó único.
- 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 em um subconjunto de nós.
- Alinha-se com as melhores práticas e expectativas de seus clientes e parceiros que procuram uma experiência confiável e consistente no Kubernetes local.
Habilitar 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 do AKS; por exemplo, New-AksHciCluster -Name <name> -controlPlaneNodeCount 3 -osType Linux -kubernetesVersion $kubernetesVersion -enableAvailabilitySet.
Como os conjuntos de disponibilidade funcionam no AKS habilitado pelo Azure Arc
Quando você cria um novo cluster do AKS Arc, o AKS Arc cria automaticamente conjuntos de disponibilidade, um para as VMs do painel de controle e outro para cada um dos pools de nós no cluster do Kubernetes. Cada pool de nós tem seu próprio conjunto de disponibilidade. Com esse layout, o AKS Arc garante que as VMs da mesma função (painel 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 versão 23H2 com dois computadores host físicos, Host A e Host B, três VMs de painel de controle e duas VMs de nó de trabalho, Nodepool1VM1 e Nodepool1VM2. Para garantir a alta disponibilidade de seus aplicativos do 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, a VM2 do Plano de Controle, a VM3 do Plano de Controle e o Nodepool1VM2 farão failover para o Host A , conforme mostrado na figura a seguir. Supondo que seu aplicativo esteja executando pods em NodePoolVM1, essa reinicialização não tem impacto em 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 (rebalanceamento), forçando assim as cargas de trabalho a permanecerem no mesmo host e criarem 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 depois que um host se recupera da 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 oferecemos suporte à configuração manual dos domínios de falha ou conjuntos de disponibilidade. Você não pode 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 computadores
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 um computador devido a problemas de hardware ou reduz verticalmente 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 um computador físico (domínio de falha) for excluído 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 do 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 é expandida automaticamente para incluir a nova máquina. No entanto, as VMs existentes não são rebalanceadas para aplicar essa nova configuração, pois já estão atribuídas a conjuntos de disponibilidade. Recomendamos que você reimplante seus clusters do Kubernetes para que o conjunto de disponibilidade seja atualizado com o número adequado de domínios de falha.