Confiabilidade no Serviço Kubernetes do Azure (AKS)

O Azure Kubernetes Service (AKS) é um serviço gerido de orquestração de contentores que simplifica a implementação, gestão e operações do Kubernetes.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Azure Kubernetes Service (AKS) resiliente a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também como pode usar backups para recuperar de outros tipos de problemas e destaca algumas informações chave sobre o acordo de nível de serviço (SLA) do Azure Kubernetes Service (AKS).

Recomendações de implantação de produção

Para obter recomendações sobre como implantar cargas de trabalho de produção confiáveis no AKS, consulte os seguintes artigos:

• Práticas recomendadas de implantação e confiabilidade de cluster para AKS
• Visão geral de alta disponibilidade (HA) e recuperação de desastres (DR) para AKS
• Considerações sobre resiliência de zona para AKS

Visão geral da arquitetura de confiabilidade

Quando você cria um cluster AKS, a plataforma Azure cria e configura automaticamente:

• Um plano de controle que tem o servidor de API, etcd, o agendador e outros pods necessários para gerenciar sua carga de trabalho.

• Um pool de nós do sistema para a sua assinatura, que hospeda os seus complementos e outros pods que são executados no namespace kube-system.

Após a conclusão da configuração inicial do pool de nós, você poderá adicionar ou excluir pools de nós para suas próprias cargas de trabalho de usuário. O AKS não gere pools de nós para garantir a fiabilidade, deve garantir que as suas cargas de trabalho sejam resilientes a falhas de infraestrutura.

A resiliência é uma responsabilidade compartilhada entre você e a Microsoft. Como um serviço de computação, o AKS gerencia alguns aspetos da confiabilidade do seu cluster, mas você é responsável por gerenciar outros aspetos.

• A Microsoft gerencia o plano de controle e outros componentes gerenciados do AKS.

• É da sua responsabilidade:

  • Defina como os componentes, incluindo pools de nós e balanceadores de carga que se conectam aos serviços, devem ser configurados para atender aos seus requisitos de confiabilidade. Depois de definir os componentes, a Microsoft os implanta e gerencia em seu nome.

  • Gerencie todos os componentes fora do cluster AKS, incluindo armazenamento e bancos de dados. Verifique se esses componentes atendem aos seus requisitos de confiabilidade. Ao implantar suas cargas de trabalho, certifique-se de que outros componentes do Azure também estejam configurados para resiliência seguindo as práticas recomendadas para esses serviços.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Quando se usa o AKS, falhas transitórias podem ocorrer por vários motivos, incluindo operações de escalonamento e balanceamento de pods, falhas de aplicativos, atualizações de nós e falhas temporárias de infraestrutura, como problemas de hardware ou de rede.

É impossível eliminar todas as falhas transitórias, portanto, os clientes que acessam seus aplicativos hospedados no AKS devem estar preparados para repetir solicitações com falha e seguir outras recomendações de tratamento de falhas transitórias. Você pode minimizar a probabilidade de falhas transitórias e evitar ou reduzir o tempo de inatividade que elas podem causar seguindo as práticas recomendadas do Kubernetes e do Azure em sua implantação.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem mudar para uma das zonas restantes.

Quando você implanta um cluster AKS em uma região que suporta zonas de disponibilidade, diferentes componentes exigem diferentes tipos de configuração.

O plano de controlo AKS é resiliente a zonas por padrão. Se uma zona falhar, o plano de controle não requer nenhuma configuração ou gerenciamento para alcançar resiliência. No entanto, a resiliência do plano de controle não é suficiente para que o cluster permaneça operacional quando uma zona falha. Para o pool de nós do sistema e quaisquer pools de nós de usuário implantados, você deve habilitar o suporte à zona de disponibilidade para ajudar a garantir que suas cargas de trabalho sejam resilientes a falhas na zona de disponibilidade.

Requerimentos

Suporte regional: Pode implementar clusters AKS resilientes a zonas em qualquer região que suporte zonas de disponibilidade.

Considerações

Para melhorar a confiabilidade e a resiliência das cargas de trabalho de produção do AKS em uma região, você precisa configurar o AKS para redundância de zona fazendo as seguintes configurações:

• Implante várias réplicas. Kubernetes espalha os seus pods por nodes com base em rótulos de nodes. Para distribuir sua carga de trabalho entre zonas, você precisa implantar várias réplicas do seu pod. Por exemplo, se você configurar o pool de nós com três zonas, mas implantar apenas uma única réplica do seu pod, sua implantação não será resiliente à zona.

• Habilite o dimensionamento automático. Os pools de nós do Kubernetes fornecem opções de dimensionamento manual e automático. Usando o dimensionamento manual, você pode adicionar ou excluir nós conforme necessário, e os pods pendentes aguardam até que você aumente a escala de um pool de nós. O dimensionamento gerido pelo AKS usa o dimensionador automático de clusters ou o autoprovisionamento de nós (NAP). O AKS dimensiona o pool de nós para cima ou para baixo com base nos requisitos do pod dentro da cota e capacidade de SKU da sua assinatura. Este método ajuda a garantir que os seus pods sejam agendados em nós disponíveis nas zonas de disponibilidade.

• Defina restrições de topologia de pod. Utilize restrições de propagação de topologia de pod para controlar como os pods são espalhados por diferentes nós ou zonas. As restrições ajudam a obter HA, resiliência e uso eficiente de recursos. Se você preferir espalhar pods estritamente entre zonas, você pode definir restrições para forçar um pod em um estado pendente para manter o equilíbrio de pods entre zonas. Para obter mais informações, consulte Restrições de propagação de topologia dos pods.

• Configure rede resiliente à zona. Se seus pods servirem tráfego externo, configure sua arquitetura de rede de cluster usando serviços como o Azure Application Gateway, o Azure Load Balancer ou o Azure Front Door.

• Certifique-se de que as dependências sejam resilientes à zona. A maioria das aplicações AKS utiliza outros serviços para armazenamento, segurança ou rede. Certifique-se de revisar as recomendações de resiliência de zona para esses serviços.

Custo

Não há nenhum custo extra para ativar o suporte à zona de disponibilidade no AKS. Você paga pelas máquinas virtuais (VMs) e outros recursos implantados nas zonas de disponibilidade.

Configurar o suporte à zona de disponibilidade

• Crie um novo cluster AKS que tenha suporte à zona de disponibilidade: Para configurar o suporte à zona de disponibilidade, consulte Criar um cluster do Serviço Kubernetes do Azure (AKS) que usa zonas de disponibilidade.
• Migração: Não é possível ativar o suporte à zona de disponibilidade depois de criar um cluster. Em vez disso, você precisa criar um novo cluster que tenha o suporte à zona de disponibilidade habilitado e excluir o cluster existente.
• Desative o suporte à zona de disponibilidade: Não é possível desativar o suporte à zona de disponibilidade depois de criar um cluster. Em vez disso, você precisa criar um novo cluster que tenha o suporte à zona de disponibilidade desabilitado e excluir o cluster existente.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando os clusters AKS são configurados para suporte a zonas de disponibilidade e todas as zonas de disponibilidade estão operacionais.

• Roteamento de tráfego entre zonas: Quando você implanta um cluster AKS que usa zonas de disponibilidade, é importante garantir que seus componentes de rede também sejam resilientes à zona. Dependendo dos balanceadores de carga e outros componentes de rede que você usa, talvez seja necessário configurar explicitamente os componentes para rotear o tráfego para os nós corretos nas zonas corretas e responder a interrupções de zona. Para obter mais informações, consulte Considerações sobre resiliência de zona para AKS.

• Replicação de dados entre zonas: Se você executar uma carga de trabalho sem monitoração de estado, deverá usar serviços gerenciados do Azure, como bancos de dados do Azure, Cache do Azure para Redis ou Armazenamento do Azure para armazenar os dados do aplicativo. Você pode usar esses serviços para ajudar a garantir que seu tráfego possa ser movido entre nós e zonas sem correr o risco de perda de dados ou afetar a experiência do usuário. Você pode usar deployments, services e health probes do Kubernetes para gerir pods sem estado e garantir uma distribuição uniforme entre zonas.

  Se você precisar armazenar o estado em seu cluster usando discos do Azure, use o armazenamento com redundância de zona do Azure para ajudar a garantir que seus dados sejam replicados em várias zonas de disponibilidade. Para obter mais informações, consulte Escolher o tipo de disco certo com base nas necessidades do aplicativo.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando ocorre uma falha na zona de disponibilidade enquanto os clusters AKS estão configurados com suporte a zonas de disponibilidade.

• Deteção e resposta: Quando ocorre uma interrupção de zona, o plano de controle faz failover automaticamente. Se os seus pools de nós usam zonas de disponibilidade e seguem as práticas recomendadas de resiliência de zona, pode esperar que o AKS lhe disponibilize nós e réplicas nas zonas que estão em operação. O AKS faz essa tarefa automaticamente quando você usa soluções gerenciadas, como cluster autoscaler ou NAP. Sem dimensionamento automático, nós e réplicas permanecem no estado Pendente e aguardam a intervenção manual para aumentar a escala do pool de nós.

  O AKS tenta reequilibrar os pods nas zonas saudáveis. Se optar por dimensionar manualmente o seu pool de nós num cenário de zone-down, os seus pods poderão permanecer no estado Pendente quando não existirem nós disponíveis nas zonas saudáveis. A expansão nas zonas restantes também está sujeita à disponibilidade de cota e capacidade para a SKU da VM que você usa.

• Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar o Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Service Health para o notificar de problemas.

  Você também pode usar suas métricas de integridade de nó ou pod para monitorar a integridade de seus nós e pods.

• Solicitações ativas: Quaisquer solicitações ativas podem sofrer interrupções. Algumas solicitações podem falhar e a latência pode aumentar enquanto a carga de trabalho comuta para outra zona.

• Perda de dados esperada: Se você armazenar o estado em seu cluster usando discos do Azure e usar armazenamento com redundância de zona, não se espera que uma falha de zona cause perda de dados.

• Tempo de inatividade esperado: Se você configurar corretamente a resiliência de zona para seu cluster e pods, não se espera que uma falha de zona cause tempo de inatividade para sua carga de trabalho do AKS.

• Reencaminhamento do tráfego: Os balanceadores de carga redirecionam os novos pedidos recebidos para pods que são executados em nós saudáveis.

Para obter mais informações, consulte Considerações sobre resiliência de zona para AKS.

Recuperação de zona

Quando a zona de disponibilidade se recupera, o comportamento de failback depende do componente:

• Plano de controlo: O AKS restaura automaticamente as operações do avião de controle em todas as zonas de disponibilidade. Não é necessária qualquer intervenção manual.

• Pools de nós e nós: Imediatamente após o failback, os nós permanecem nas zonas anteriormente íntegras e não são restaurados na zona recuperada. No entanto, da próxima vez que você executar uma operação de dimensionamento de nós, como quando dimensionar o pool de nós, o pool de nós poderá criar nós na zona recuperada.

• Pods: Imediatamente após o failback, os pods continuam a ser executados nos nós em que são executados atualmente. Quando novos pods são criados ou pods existentes são recriados, tornam-se elegíveis para utilizar nós na zona que foi recuperada.

• Armazenamento: Qualquer armazenamento ligado aos pods é recuperado com base no funcionamento do armazenamento com redundância de zona.

Teste de falhas de zona

Você pode testar sua resiliência a falhas de zona de disponibilidade usando os seguintes métodos:

• Cordão e nós de drenagem em uma única zona de disponibilidade
• Simular uma falha de zona de disponibilidade usando o Azure Chaos Studio

Resiliência a falhas em toda a região

Os clusters AKS são recursos de uma única região. Se a região não estiver disponível, o cluster AKS também não estará disponível.

Soluções personalizadas de várias regiões para resiliência

Se você precisar implantar sua carga de trabalho do Kubernetes em várias regiões do Azure, terá duas opções para gerenciar a orquestração desses clusters.

• Use o Azure Kubernetes Fleet Manager se quiser uma experiência mais simples e gerenciada. Usando o Azure Kubernetes Fleet Manager, você pode:

  • Gerencie um conjunto de clusters AKS como uma única unidade, e esses clusters podem ser distribuídos em várias regiões do Azure.

  • Automatize aspetos específicos do gerenciamento de clusters, como atualizações de imagens de cluster e nós.

  • Use os recursos de distribuição de tráfego para distribuir o tráfego entre os clusters e fazer failover automaticamente se uma região não estiver disponível.

• Orquestre a comutação por falha usando um modelo de implementação ativo-ativo ou ativo-passivo manual se a sua carga de trabalho exigir um controlo mais matizado sobre os diferentes componentes de comutações por falha inter-regionais. Para obter mais informações, consulte Visão geral de HA e DR para AKS.

Backup e restauração

O Backup do Azure tem uma extensão que você pode usar para fazer backup de recursos de cluster AKS e volumes persistentes que se conectam ao cluster. O cofre de backup se comunica com o cluster AKS através da extensão para executar operações de backup e restauração.

Se o cluster AKS estiver em uma região emparelhada, você poderá configurar backups para serem armazenados em armazenamento com redundância geográfica. É possível restaurar backups com redundância geográfica na região emparelhada.

Para obter mais informações, consulte os seguintes artigos:

• O que é o Azure Kubernetes Service?
• Fazer backup do AKS usando o Backup do Azure

Para a maioria das soluções, você não deve confiar exclusivamente em backups. Em vez disso, use os outros recursos descritos neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não oferecem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

Esforce-se para usar clusters sem estado que minimizem a necessidade de backup. Armazene dados em sistemas de armazenamento externos e bancos de dados em vez de dentro do cluster.

Resiliência à manutenção de serviços

O AKS realiza a manutenção do seu cluster, incluindo atualizações das imagens do cluster e do nó. Para garantir que o Kubernetes mantenha o número mínimo de instâncias de pod necessárias para atender ao seu tráfego de produção, mesmo durante as atualizações, você deve configurar seus pods para usar orçamentos de interrupção de pod.

Para reduzir as interrupções de serviço durante períodos críticos, o AKS fornece controles para que você possa especificar os tempos de manutenção planejados. Para saber mais, consulte Usar manutenção planejada para agendar e controlar atualizações para seu cluster do Serviço Kubernetes do Azure.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

O AKS fornece três níveis de preços para gerenciamento de cluster: Gratuito, Standard e Premium. O nível Gratuito permite que você use o AKS para testar suas cargas de trabalho. As camadas Standard e Premium são projetadas para cargas de trabalho de produção. Quando você implanta um cluster AKS com zonas de disponibilidade habilitadas, a porcentagem de tempo de atividade definida no SLA aumenta. No entanto, o SLA se aplica somente se você implantar um cluster no nível de preço Standard ou Premium.

Conteúdo relacionado

• Fiabilidade no Azure