Compartilhar via


Disponibilidade do aplicativo no AKS habilitado pelo Azure Arc

Aplica-se ao: AKS no Azure Local 22H2, AKS no Windows Server

O AKS (Serviço de Kubernetes do Azure) habilitado pelo Azure Arc oferece uma plataforma de contêiner com suporte total que pode executar aplicativos nativos de nuvem na plataforma de orquestração de contêiner do Kubernetes. A arquitetura dá suporte à execução de cargas de trabalho virtualizadas do Windows e do Linux.

A arquitetura do AKS é criada com clustering de failover e migração dinâmica que é habilitada automaticamente para clusters de destino (carga de trabalho). Durante vários eventos de interrupção, as máquinas virtuais que hospedam cargas de trabalho do cliente são movidas livremente sem tempo de inatividade percebido do aplicativo. Essa arquitetura significa que um cliente corporativo tradicional, que está gerenciando um aplicativo herdado como um singleton para o AKS no Azure Local ou no Windows Server, obtém um tempo de atividade semelhante (ou melhor) do que o que é experimentado atualmente em um aplicativo de VM herdado.

Este artigo descreve alguns conceitos fundamentais para usuários que desejam executar aplicativos em contêineres no AKS Arc com a migração dinâmica habilitada para garantir que os aplicativos estejam disponíveis durante uma interrupção. A terminologia do Kubernetes, como interrupção voluntária e interrupção involuntária, é usada para se referir ao tempo de inatividade de um aplicativo em execução em um pod.

O que é migração ao vivo?

A migração dinâmica é um recurso do Hyper-V que permite mover de forma transparente máquinas virtuais em execução de um host Hyper-V para outro sem tempo de inatividade percebido. O principal benefício da migração ao vivo é a flexibilidade; A execução de máquinas virtuais não está vinculada a um único computador host. Isso permite que os usuários executem ações como drenar um host específico de máquinas virtuais antes de desativar ou atualizar o host. Quando emparelhada com o Clustering de Failover do Windows, a migração dinâmica permite a criação de sistemas altamente disponíveis e tolerantes a falhas.

A arquitetura atual do AKS no Azure Local e no Windows Server pressupõe que você habilitou a migração dinâmica em seu ambiente clusterizado Local do Azure. Portanto, todas as VMs de nó de trabalho do Kubernetes são criadas com a migração dinâmica configurada. Esses nós podem ser movidos em hosts físicos em caso de interrupção para garantir que a plataforma esteja altamente disponível.

Diagrama mostrando o AKS no Azure Local e no Windows Server com o Clustering de Failover habilitado.

Quando você executa um aplicativo legado como um singleton sobre o Kubernetes, essa arquitetura atende às suas necessidades de alta disponibilidade. O Kubernetes gerencia o agendamento de pods em nós de trabalho disponíveis, enquanto a migração ao vivo gerencia o agendamento de VMs de nó de trabalho em hosts físicos disponíveis.

Diagrama mostrando um exemplo de aplicativo herdado em execução como um singleton.

Cenários de interrupção de aplicativos

Um estudo comparativo dos tempos de recuperação para aplicativos em execução em VMs no AKS no Azure Local e no Windows Server mostra claramente que há um impacto mínimo no aplicativo quando ocorrem eventos comuns de interrupção. Três exemplos de cenários de interrupção incluem:

  • Aplicar uma atualização que resulta em uma reinicialização da máquina física.
  • Aplicando uma atualização que envolve a recriação do nó de trabalho.
  • Falha de hardware não planejada de uma máquina física.

Observação

Esses cenários pressupõem que o proprietário do aplicativo ainda use as configurações de afinidade e antiafinidade do Kubernetes para garantir o agendamento adequado de pods entre nós de trabalho.

Evento de interrupção Executando aplicativos em VMs no Azure Local Executando aplicativos em VMs no AKS no Azure Local ou Windows Server
Aplicar uma atualização que resulte em uma reinicialização da máquina física Sem impacto Sem impacto
Aplicar uma atualização que envolva a recriação do nó de trabalho (ou a reinicialização da VM) Sem impacto Varia
Falha de hardware não planejada de uma máquina física 6-8 minutos 6-8 minutos

Aplicar uma atualização que resulte em uma reinicialização da máquina física

Durante um evento de manutenção de host físico, como a aplicação de uma atualização que resulta na reinicialização de uma máquina host, nenhum impacto é esperado para aplicativos em execução no cluster. O administrador de cluster drena o host e garante que todas as VMs sejam migradas ao vivo antes de aplicar a atualização.

Aplicar uma atualização que envolva a recriação do nó de trabalho

Esse cenário envolve a inatividade de uma VM de nó de trabalho para executar a manutenção de rotina. Para se preparar para a atualização, o administrador do cluster drena e isola o nó, para que todos os pods sejam removidos para um nó de trabalho disponível antes de aplicar as atualizações. Depois que a atualização for concluída, o nó de trabalho será reingressado e disponibilizado para agendamento.

Observação

A disponibilidade de um aplicativo varia, pois inclui o tempo necessário para baixar a imagem do contêiner base, especialmente para imagens maiores armazenadas na nuvem pública. Portanto, é recomendável usar imagens de contêiner base pequenas e, para contêineres do Windows, é recomendável usar a nano server imagem base.

Falha de hardware não planejada de uma máquina física

Nesse cenário, ocorre um evento de interrupção involuntária em uma máquina física que hospeda um contêiner/pod de aplicativo herdado em uma das VMs do nó de trabalho. O clustering de failover coloca o host em um estado isolado e, após um período de 6 a 8 minutos, inicia o processo de migração dinâmica dessas VMs para hosts sobreviventes. Nesse caso, o tempo de inatividade do aplicativo é o equivalente ao tempo necessário para reiniciar as VMs do host e do nó de trabalho.

Conclusão

As tecnologias de clustering de failover do AKS são projetadas para garantir que os ambientes de computação no Azure Local e no Windows Server sejam altamente disponíveis e tolerantes a falhas. No entanto, o proprietário do aplicativo ainda precisa configurar implantações para usar recursos do Kubernetes, como Deployments, Affinity Mapping, , RelicaSetspara garantir que os pods sejam resilientes em cenários de interrupção.

Próximas etapas

Visão geral do AKS no Windows Server e no Azure Local