Disponibilidade da aplicação no AKS ativada pelo Azure Arc

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Azure Kubernetes Service (AKS) ativado pelo Azure Arc oferece uma plataforma de contentores totalmente suportada que pode executar aplicações nativas da cloud na plataforma de orquestração de contentores do Kubernetes. A arquitetura suporta a execução de cargas de trabalho virtualizadas do Windows e do Linux.

A arquitetura do AKS é criada com clustering de ativação pós-falha e migração em direto que é ativada automaticamente para clusters de destino (carga de trabalho). Durante vários eventos de interrupção, as máquinas virtuais que alojam cargas de trabalho dos clientes são movidas livremente sem um tempo de inatividade de aplicações percepcionado. Esta arquitetura significa que um cliente empresarial tradicional, que está a gerir uma aplicação legada como singleton para o AKS no Azure Stack HCI ou Windows Server, obtém um tempo de atividade semelhante (ou melhor) semelhante ao que é atualmente experimentado numa aplicação de VM legada.

Este artigo descreve alguns conceitos fundamentais para os utilizadores que pretendem executar aplicações em contentores no AKS Arc com a migração em direto ativada para garantir que as aplicações estão disponíveis durante uma interrupção. A terminologia do Kubernetes, como a interrupção voluntária e a interrupção involuntária, é utilizada para referir o tempo de inatividade de uma aplicação em execução num pod.

O que é a migração em direto?

A migração em direto é uma funcionalidade hyper-V que lhe permite mover de forma transparente máquinas virtuais em execução de um anfitrião Hyper-V para outro sem tempo de inatividade percebido. O principal benefício da migração em direto é a flexibilidade; A execução de máquinas virtuais não está ligada a uma única máquina anfitriã. Isto permite que os utilizadores executem ações como drenar um anfitrião específico de máquinas virtuais antes de desativar ou atualizar o anfitrião. Quando emparelhada com o Clustering de Ativação Pós-falha do Windows, a migração em direto permite a criação de sistemas de elevada disponibilidade e tolerantes a falhas.

A arquitetura atual do AKS no Azure Stack HCI e no Windows Server pressupõe que ativou a migração em direto no ambiente agrupado do Azure Stack HCI. Por conseguinte, todas as VMs de nó de trabalho do Kubernetes são criadas com a migração em direto configurada. Estes nós podem ser movidos em torno de anfitriões físicos em caso de interrupção para garantir que a plataforma está altamente disponível.

Quando executa uma aplicação legada como singleton na parte superior do Kubernetes, esta arquitetura satisfaz as suas necessidades de elevada disponibilidade. O Kubernetes gere o agendamento de pods em nós de trabalho disponíveis enquanto a migração em direto gere o agendamento de VMs de nós de trabalho em anfitriões físicos disponíveis.

Cenários de interrupção da aplicação

Um estudo comparativo dos tempos de recuperação das aplicações em execução em VMs no AKS no Azure Stack HCI e no Windows Server mostra claramente que existe um impacto mínimo na aplicação quando ocorrem eventos de interrupção comuns. Três cenários de interrupção de exemplo incluem:

• Aplicar uma atualização que resulta num reinício da máquina física.
• Aplicar uma atualização que envolve recriar o nó de trabalho.
• Falha de hardware não planeada de um computador físico.

Nota

Estes cenários pressupõem que o proprietário da aplicação ainda utiliza as definições de afinidade e anti-afinidade do Kubernetes para garantir o agendamento adequado de pods entre nós de trabalho.

Evento de interrupção	Executar aplicações em VMs no Azure Stack HCI	Executar aplicações em VMs no AKS no Azure Stack HCI ou no Windows Server
Aplicar uma atualização que resulta num reinício da máquina física	Sem impacto	Sem impacto
Aplicar uma atualização que envolva recriar o nó de trabalho (ou reiniciar a VM)	Sem impacto	Varia
Falha de hardware não planeada de um computador físico	6 a 8 minutos	6 a 8 minutos

Aplicar uma atualização que resulta num reinício da máquina física

Durante um evento de manutenção do anfitrião físico, como a aplicação de uma atualização que resulta no reinício de um computador anfitrião, não é esperado qualquer impacto para as aplicações em execução no cluster. O administrador do cluster drena o anfitrião e garante que todas as VMs são migradas em direto antes de aplicar a atualização.

Aplicar uma atualização que envolva recriar o nó de trabalho

Este cenário envolve derrubar uma VM de nó de trabalho para efetuar 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 expulsos para um nó de trabalho disponível antes de aplicar atualizações. Assim que a atualização estiver concluída, o nó de trabalho é reencontrado e disponibilizado para agendamento.

Nota

A disponibilidade de uma aplicação varia, uma vez que inclui o tempo que demora a transferir a imagem de contentor base, especialmente para imagens maiores armazenadas na cloud pública. Por conseguinte, recomenda-se que utilize imagens de contentores de base pequenas e, para contentores do Windows, recomenda-se que utilize a nano server imagem de base.

Falha de hardware não planeada de um computador físico

Neste cenário, ocorre um evento de interrupção involuntária numa máquina física que aloja um contentor/pod de aplicação legado numa das VMs do nó de trabalho. O clustering de ativação pós-falha coloca o anfitrião num estado isolado e, após um período de 6 a 8 minutos, inicia o processo de migração em direto destas VMs para anfitriões sobreviventes. Neste caso, o tempo de inatividade da aplicação é o equivalente ao tempo que demora a reiniciar as VMs do nó de anfitrião e de trabalho.

Conclusão

As tecnologias de clustering de ativação pós-falha do AKS foram concebidas para garantir que os ambientes de computação no Azure Stack HCI e no Windows Server são altamente disponíveis e tolerantes a falhas. No entanto, o proprietário da aplicação ainda tem de configurar implementações para utilizar funcionalidades do Kubernetes, como Deployments, Affinity Mapping, RelicaSetspara garantir que os pods são resilientes em cenários de interrupção.

Passos seguintes

Descrição geral do AKS no Windows Server e no Azure Stack HCI