Confiabilidade no AKS (Serviço de Kubernetes do Azure)

Este artigo descreve o suporte à confiabilidade no AKS (Serviço de Kubernetes do Azure), abrangendo a resiliência intra-regional por meio de zonas de disponibilidade e implantações de várias regiões.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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.

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 confiabilidade de cluster e implantação 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 o AKS

Visão geral da arquitetura de confiabilidade

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

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

• Um pool de nós do sistema para sua assinatura que hospeda seus complementos e outros pods executados no namespace do sistema kube.

Depois que essa configuração inicial do pool de nós for concluída, você poderá adicionar ou excluir pools de nós para suas próprias cargas de trabalho de usuário. O AKS não gerencia pools de nós para confiabilidade e você deve garantir que 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 aspectos da confiabilidade do cluster, mas você é responsável por gerenciar outros aspectos.

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

• É sua responsabilidade:

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

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

Falhas transitórias

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

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

Ao usar o AKS, falhas transitórias podem ocorrer devido a vários motivos, incluindo falhas de aplicativo, operações de dimensionamento e balanceamento de pods, aplicação de patch de nó e falhas de infraestrutura temporárias, como problemas de hardware ou de rede.

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

• Defina os PDBs (orçamentos de interrupção do pod) no YAML do pod para especificar quantos pods você precisa ter em um determinado estado Ready em um determinado momento. Quando você define PDBs, o AKS garante uma disponibilidade mínima de réplicas quando executa operações para isolar e drenar os nós. Se um PDB não puder ser satisfeito durante processos como atualizações, o pod continuará funcionando e a operação poderá falhar. Para obter mais informações, consulte PDBs.

• Use maxUnavailable para definir o número máximo de réplicas que podem ficar indisponíveis em um determinado momento. Por exemplo, quando você executa uma reinicialização sem interrupção, o AKS garante que não mais do que o número maxUnavailable de pods seja alterado em um determinado momento. Para obter mais informações, consulte maxUnavailable.

• Siga as práticas recomendadas de implantação. As réplicas de pod também podem falhar devido a problemas de aplicativo. Para obter mais informações, consulte as práticas recomendadas no nível de implantação para a confiabilidade do cluster do AKS.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

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

O plano de controle do AKS é resiliente à zona por padrão. Se uma zona falhar, o plano de controle não exigirá nenhuma configuração ou gerenciamento para obter resiliência. No entanto, a resiliência do plano de controle não é suficiente para que o cluster permaneça operacional quando uma zona falhar. Para o pool de nós do sistema e todos os pools de nós de usuário que você implantar, 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.

Suporte de regiões

Você pode implantar clusters AKS resilientes à zona em qualquer região que dê suporte a zonas de disponibilidade.

Considerações

Para aprimorar 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:

• Implantar várias réplicas. O Kubernetes espalha seus pods nos nós com base em rótulos de nó. 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 pod, sua implantação não será resiliente à zona.

• Habilitar 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 esperam até que você dimensione um pool de nós. O dimensionamento gerenciado pelo AKS usa o dimensionador automático de cluster ou 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. Esse método ajuda a garantir que seus pods sejam alocados em nós disponíveis dentro das zonas de disponibilidade.

• Definir restrições de topologia de pod. Use restrições de propagação de topologia de pod para controlar como os pods são distribuídos entre diferentes nós ou zonas. As restrições ajudam você a obter HA, resiliência e uso eficiente de recursos. Se você preferir distribuir pods uniformemente entre zonas, pode definir restrições para colocar um pod em estado pendente, mantendo assim o equilíbrio de pods entre as zonas. Para obter mais informações, confira Restrições de distribuição de topologia de pods.

• Configure rede resistente a falhas de zona. Se os pods atenderem ao tráfego externo, configure sua arquitetura de rede de cluster usando serviços como o Gateway de Aplicativo do Azure, o Azure Load Balancer ou o Azure Front Door.

• Verifique se as dependências são resilientes em zonas. A maioria dos aplicativos AKS usa outros serviços para armazenamento, segurança ou rede. Verifique se você revisou as recomendações de resiliência de zona para esses serviços.

Custo

Não há cobrança adicional para habilitar o suporte à zona de disponibilidade no AKS. Você paga pelas máquinas virtuais (VMs) e outros recursos que implanta nas zonas de disponibilidade.

Configurar o suporte à zona de disponibilidade

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

Operações normais

• Roteamento de tráfego entre zonas: Quando você implanta um cluster do AKS que usa zonas de disponibilidade, é importante garantir que os componentes de rede também sejam resilientes à zona. Dependendo dos balanceadores de carga e de 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 de resiliência de zona para o AKS.

• Replicação de dados entre zonas: Se você executar uma carga de trabalho sem 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 o tráfego possa ser movido entre nós e zonas sem arriscar a perda de dados ou afetar a experiência do usuário. Você pode usar as implantações, serviços e investigações de integridade do Kubernetes para gerenciar os pods sem estado e garantir a distribuição uniforme entre as 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 correto com base nas necessidades do aplicativo.

Experiência de redução de atividade na zona

• Detecção e resposta: quando ocorre uma interrupção de zona, o plano de controle faz failover automaticamente. Se os pools de nós usarem zonas de disponibilidade e seguirem as práticas recomendadas de resiliência de zona, você poderá esperar que o AKS traga nós e réplicas nas zonas que estão operacionais. O AKS faz essa tarefa automaticamente quando você usa soluções gerenciadas, como dimensionador automático de cluster ou NAP. Sem dimensionamento automático, nós e réplicas permanecem no estado Pendente e aguardam a intervenção manual para escalar verticalmente o pool de nós.

  O AKS também tenta reequilibrar os pods entre as zonas íntegras. Se você optar por dimensionar manualmente o pool de nós em um cenário de redução de zona, seus pods poderão permanecer no estado Pendente quando não houver nós disponíveis nas zonas íntegras. O dimensionamento nas zonas restantes também está sujeito à disponibilidade de cota e capacidade para a SKU da VM que você usa.

• Notificação: O AKS não notifica você quando uma zona está inoperante. No entanto, você pode usar o Azure Resource Health para monitorar a integridade do cluster. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço AKS, incluindo quaisquer falhas de zona.

  Configure alertas nesses serviços para receber notificações de problemas da zona. Para obter mais informações, veja Criar alertas da Integridade do Serviço no portal do Azure e Criar e configurar alertas do Resource Health.

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

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

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

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

• Redirecionamento de tráfego: Os balanceadores de carga redirecionam novas solicitações de entrada para os pods que operam em nós saudáveis.

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

Recuperação de zona

Quando a zona de disponibilidade é recuperada, o comportamento de failback depende do componente:

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

• Pools de nós e nós: imediatamente após o failback, os nós permanecem nas zonas previamente saudáveis e não são restaurados na zona recuperada. No entanto, na próxima vez que você executar uma operação de dimensionamento de nó, como quando você 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 estão sendo executados no momento. Quando novos pods são criados ou pods existentes são recriados, eles ficam aptos a utilizar os nós na zona recuperada.

• Armazenamento: qualquer armazenamento anexado a pods é recuperado com base em como o armazenamento com redundância de zona funciona.

Testar falhas em zonas

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 na zona de disponibilidade usando o Azure Chaos Studio

Suporte para várias regiões

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

Abordagens alternativas de várias regiões

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 Gerenciador de Frotas do Kubernetes do Azure se desejar uma experiência gerenciada mais simples. Usando o Gerenciador de Frotas do Kubernetes do Azure, você pode:

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

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

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

• Orquestre o failover usando um modelo de implantação ativo-ativo ou ativo-passivo manual se a carga de trabalho exigir um controle mais matizado sobre os diferentes componentes de failovers inter-regionais. Para obter mais informações, consulte a visão geral de HA e DR para AKS.

Cópias de segurança

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

Se o cluster do AKS estiver em uma região emparelhada, você poderá configurar backups a serem armazenados no armazenamento com redundância geográfica. Você pode restaurar os backups geograficamente redundantes na região emparelhada.

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

• O que é o backup do Serviço de Kubernetes do Azure?
• Fazer backup do AKS usando o Backup do Azure

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte 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.

Confiabilidade durante a manutenção do serviço

O AKS executa a manutenção em seu cluster, incluindo atualizações para o cluster e imagens de nó. Para garantir que o Kubernetes mantenha o número mínimo de instâncias de pod necessárias para atender ao tráfego de produção mesmo durante as atualizações, você deve configurar seus pods para usar os orçamentos de interrupção do 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, confira Usar a manutenção planejada para agendar e controlar atualizações para o cluster do Serviço de Kubernetes do Azure.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para AKS descreve a disponibilidade esperada do serviço e as condições que devem ser atendidas para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O AKS fornece três tipos de preços para gerenciamento de cluster: Gratuito, Standard e Premium. A camada Gratuita 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 do AKS que tem zonas de disponibilidade habilitadas, o percentual de tempo de atividade definido no SLA aumenta. No entanto, o SLA só se aplicará se você implantar um cluster na categoria de preço Standard ou Premium.

Conteúdo relacionado

• Confiabilidade no Azure