Alta disponibilidade para aplicações AKS multinível

Este artigo discute a alta disponibilidade (HA) para implementação de aplicações multinível em clusters Azure Kubernetes Service (AKS). Descreve os mecanismos e construções do HA do Kubernetes, e fornece uma lista de verificação e diretrizes para identificar e eliminar pontos únicos de falha do AH.

Existem duas tarefas fundamentais para implementar HA em aplicações AKS:

  • Identifique todos os pontos únicos de falha na aplicação.
  • Elimine os pontos únicos de falha.

Para eliminar pontos únicos de falha, é necessária uma solução de alta disponibilidade (HA).

Os quatro pilares da HA

Quatro pilares de HA aparecem em todos os sistemas altamente disponíveis:

  • Redundancy
  • Monitoring
  • Recovery
  • Pontos de verificação

Considere a seguinte aplicação AKS multinível, onde o tráfego chega ao nível de lógica de negócio, o nível de dados preserva o estado e a aplicação devolve respostas aos utilizadores.

Diagrama que mostra uma aplicação AKS multinível.

Identificar pontos únicos de falha

Para identificar pontos únicos de falha, comece por determinar o caminho crítico entre os pedidos do cliente e os componentes que servem esses pedidos. Qualquer componente ao longo deste percurso que não seja gerido em conformidade com os quatro pilares da HA, ou com três pilares caso se trate de um componente sem estado e sem criação de pontos de controlo, constitui um ponto único de falha. Mesmo um componente replicado é considerado um ponto único de falha se não for monitorizado, porque a sua falha passa silenciosamente despercebida.

Eliminar pontos únicos de falha

Para eliminar pontos únicos de falha, implemente a sua aplicação para replicar componentes críticos do caminho e empregue balanceadores de carga, mecanismos de monitorização e recuperação. O Kubernetes consegue lidar com todas estas atividades.

Diagrama que mostra componentes replicados numa aplicação AKS multinível.

Descarregue um ficheiro Visio deste diagrama.

Numa aplicação replicada:

  • Replicas os componentes do nível de negócio com vários números de réplicas por componente, dependendo do seu desempenho e carga de trabalho.
  • Também replicas a camada de dados atrás de um balanceador de carga.

O Kubernetes fornece vários recursos e mecanismos, como balanceamento de carga e sondas de atividade, que podem ajudar a implementar os pilares da HA. A lista de verificação e discussão seguintes dividem estes construtos e mecanismos em categorias que correspondem aos quatro pilares da HA.

Lista de verificação do Kubernetes HA

Para além da gestão do estado, o Kubernetes faz um trabalho excecional na manutenção da HA das aplicações. A lista de verificação do HA lista configurações comuns que pode usar para otimizar a gestão do HA do Kubernetes. Para usar a lista de verificação, avalie a sua implementação do Kubernetes com os seguintes mecanismos e construções, e implemente os que estejam em falta.

pilar HA Solução
Redundancy ☐ Tipo de controlador Kubernetes
☐ Número de réplicas
☐ Anti-afinidade no agendamento
Monitoring ☐ Sondas de vivacidade
☐ Sondas de prontidão
☐ Verificações de arranque
Recovery ☐ Tipo de serviço
☐ Eleição do líder
☐ Política de reinício
☐ Anzóis antes da paragem
Pontos de verificação ☐ Pedidos de volume persistente
☐ Volumes persistentes

Redundancy

A redundância elimina um ponto único de falha. É necessário redundância em todos os níveis de uma aplicação. Para alcançar redundância, replicas um componente de um determinado nível com uma ou mais réplicas idênticas.

  • Tipo de comando. Configuração: kind: Deployment. O Kubernetes disponibiliza vários controladores que podem gerir o ciclo de vida do pod da sua aplicação. O controlador mais popular é Deployment. Statefulset, outro controlador, é útil quando é necessário manter a identidade do pod após a recuperação. Outros controladores, como Replicasets, não oferecem a mesma funcionalidade útil, como reversões, que Deployment proporciona.

  • Número de réplicas. Configuração: spec.replicas. Definir o número de réplicas para apenas uma configura um modelo de reserva a frio. Se usar um modelo de espera a frio, quando ocorre uma falha, uma nova instância começa do zero, o que afeta a disponibilidade. Este modelo pode funcionar para componentes com cargas de trabalho de baixo volume, mas considere replicar componentes sem estado e de alto volume.

    Ao especificar os limites de pedidos de recursos, spec.containers[].resources, pode adicionar autoscaling horizontal pod (HPA), que faz com que o Kubernetes escale automaticamente para cima ou para baixo o número de réplicas com base nos limiares de utilização de recursos que definir. O HPA ajuda-o a evitar cenários em que um pico de carga impede a sua aplicação de atender pedidos devido à sobrecarga.

  • Anti-afinidade no agendamento. Configuração: spec.affinity.podAntiAffinity. Um cluster Kubernetes típico ao nível de produção tem nós distribuídos por múltiplas zonas de disponibilidade, que se configuram usando um topologyKey. Pods com a mesma implantação devem ter anti-afinidade preferencial ou suave entre si. Esta configuração assegura que os pods agendam em nós em diferentes zonas de disponibilidade.

    Um cluster AKS pode ter múltiplos pools de nós, cada um com diferentes tamanhos de escala e especificações de máquinas virtuais. Por exemplo, pode hospedar os seus pods de base de dados em nós com discos de estado sólido (SSDs) rápidos, e alojar os seus pods de aprendizagem automática em nós com unidades de processamento gráfico (GPUs).

Monitoring

Se não monitorizar a sua aplicação, a redundância pode deixar de ser eficaz. É necessário um mecanismo de monitorização constante para garantir que a carga de trabalho chega a uma réplica em bom estado.

  • Sondas de Liveness, configuração spec.containers.livenessProbe, monitorizar a saúde dos teus pods. Se um contentor falhar ou sair, o Kubernetes pode detetá-lo. Quando a vivacidade falha, o Kubernetes reinicia o contentor.

  • Sondas de prontidão, configuração spec.containers.readinessProbe, determinam se o tráfego deve ser enviado para o pod. Se algum pod de uma implementação não estiver pronto, não fará parte dos endpoints do serviço Kubernetes que abstrai a implementação e, por isso, não será útil. É importante configurar cuidadosamente as sondas de prontidão, porque não desencadeiam um reinício, mas são usadas para impedir que os pods recebam tráfego até estarem prontos.

  • As sondas de arranque, quando configuradas spec.containers.startupProbe, servem principalmente para evitar falsos positivos nas verificações de prontidão e de atividade em aplicações com arranque lento. Depois de a sonda de arranque ser bem-sucedida, a sonda de atividade é iniciada.

O Azure fornece insights mais profundos que lhe permitem definir alertas com base no estado do seu cluster.

Recovery

O principal objetivo da monitorização é desencadear a recuperação quando detetar uma falha. Um processo de recuperação envolve três fases:

  1. Isolar e redirecionar: Certifique-se de que a réplica defeituosa não está a receber tráfego e direcione a sua carga de trabalho para réplicas saudáveis.
  2. Reparação: Reinicia a réplica defeituosa. Ao fazê-lo, podem reparar erros transitórios.
  3. Regresso: Após a reparação, se a monitorização considerar a réplica saudável, volte a juntar a réplica a outras réplicas para gerir a carga de trabalho.

O Kubernetes fornece os seguintes mecanismos para implementar estas fases:

  • Tipo de serviço. Configuração: spec.type. Expor os seus pods através de um serviço pode ser classificado como redundância ou recuperação. No entanto, em alguns casos, pode usar uma implementação de réplica única. Ainda há vantagens em expor os pods através de um serviço, mesmo que não haja balanceamento de carga.

    A principal vantagem de utilizar o serviço é que as entradas do Sistema de Nomes de Domínio (DNS) atualizam-se automaticamente com os endpoints do serviço Kubernetes. Um pod que tenha contentores com sondas de prontidão a falhar não receberá tráfego através do AKS. Embora a capacidade de balanceamento de carga dos serviços ClusterIP do Kubernetes seja rudimentar, é possível combinar um serviço headless com o Ingress ou com outras soluções de service mesh para distribuir melhor a carga.

    O mecanismo pelo qual o tráfego externo chega ao seu cluster AKS está fora do âmbito do Kubernetes. Pode gerir tráfego externo utilizando serviços como o Gateway de Aplicação do Azure.

  • Eleição de líder. Alguns componentes são mais bem implementados como singletons. O agendador é um desses componentes, porque dois agendadores ativos podem entrar em conflito entre si. O recurso a um singleton expõe a aplicação a problemas de standby a frio. Para ativar o modo de espera ativa de um pod, pode utilizar a eleição do líder, em que apenas um pod, o líder, processa os pedidos.

  • Política de reinício Configuração: spec.restartPolicy. A política de reinício aplica-se a todos os contentores do pod. Deverá haver uma justificação válida para definir este atributo como Never. Alguns contentores contactam um servidor de licenças sempre que começam, e pode querer evitar os custos adicionais de reinícios excessivos.

  • Ganchos antes da paragem. Configuração: spec.containers.lifecycle.preStop. Os hooks de pré-paragem são executados antes de um sinal SIGTERM ser enviado para o contentor. Um script de pré-paragem pode ser tão simples como um comando de espera de 30 segundos.

    Por exemplo, quando uma aplicação gerida por um HPA está a ser reduzida em escala, os pedidos em curso podem ser terminados abruptamente, a menos que a aplicação tenha um processador SIGTERM que conclua o processamento dos pedidos antes de terminar. Um gancho pre-stop remove o ponto final pod, e portanto a entrada DNS, do endpoint do serviço. Enquanto o gancho pré-paragem estiver a funcionar, não podem ser enviados novos pedidos ao pod. O hook de pré-paragem permite ao pod concluir o processamento dos pedidos em curso sem receber novos. Os hooks de pré-paragem são uma forma simples de minimizar pedidos perdidos sem alterar o código da aplicação.

Pontos de verificação

As aplicações modernas contêm muitos componentes sem estado, mas as aplicações totalmente sem estado continuam a ser raras. A maioria das aplicações verifica o seu estado na camada de dados. O Kubernetes intencionalmente não fornece qualquer mecanismo para lidar com o estado da aplicação. A gestão de estados é uma tarefa complexa que não faz parte da gestão de contentores.

Pode persistir o estado da aplicação em três níveis:

  • O nível dos registos de dados armazena os dados numa base de dados. Cada registo de base de dados pode replicar-se em múltiplas instâncias de base de dados. Os registos de bases de dados são a forma dominante de persistência de estado, especialmente em bases de dados geridas na nuvem como o Azure Cosmos DB.

  • O nível do sistema de ficheiros tipicamente replica ficheiros de dados, como ficheiros de registo antecipado (WAL). A maioria dos fornecedores de cloud oferece plugins para as suas soluções. Por exemplo, o Ficheiros do Azure fornece um plugin.

  • O nível do disco mantém os dados ao nível do bloco, o que proporciona flexibilidade para definir o sistema de ficheiros a utilizar, como no Armazenamento de Discos do Azure.

Os volumes do Kubernetes, os volumes persistentes e os pedidos de volumes persistentes podem preservar o estado da aplicação ao nível do sistema de ficheiros ou do disco. O padrão mais comum para armazenar o estado continua a ser o nível dos registos de dados.

HA e DR

Tanto para HA como para recuperação de desastres (DR), as escolhas de topologia de rede e soluções de balanceamento de carga são importantes.

No entanto, o DR requer a implementação de serviços multirregional em todo o nível do serviço, com soluções de balanceamento de carga entre regiões do Azure. A aplicação é implementada em várias regiões, ou uma instância inteira de aplicação é implementada em cada região. A escolha depende do tipo de aplicação, da arquitetura da aplicação e da tolerância de latência entre componentes.

O HA beneficia de implementações multizona dentro das regiões do Azure em vez do uso de múltiplas regiões. O diagrama seguinte ilustra a diferença entre zonas de disponibilidade e regiões para HA e DR.

Diagrama que compara zonas de disponibilidade e regiões Azure para HA e DR.

Descarregue um ficheiro Visio desta arquitetura.

Este artigo foca-se na HA ao nível da aplicação dentro de um cluster AKS. Para mais informações sobre DR em implementações multi-cluster do AKS, consulte a linha de base do AKS para clusters multirregionais.

Outras considerações

  • Para manter a HA da aplicação, certifique-se de que o seu plano de controlo Kubernetes, incluindo o servidor API e o gestor de controladores, está altamente disponível. Utilize o escalão de preço Standard ou Premium para garantir a HA.

  • Uma estratégia de consolidação de recursos contraria diretamente o pilar de despedimento da HA. Por isso, deve analisar cuidadosamente o custo do despedimento. A calculadora de preços do Azure pode ajudar.

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

  • Ali Kanso | Engenheiro de Software Principal

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Passos seguintes

  • Last updated on