Considerações sobre o gerenciamento de operações do Serviço de Kubernetes do Azure

  • Artigo

O Kubernetes é uma tecnologia relativamente nova, que evolui rapidamente com um ecossistema impressionante. Sendo assim, pode ser desafiador gerenciá-lo e protegê-lo.

Linha de base de operações do AKS

Você pode trabalhar em direção à excelência operacional e ao sucesso do cliente projetando corretamente sua solução de Serviço de Kubernetes do Azure (AKS) com o gerenciamento e o monitoramento em mente.

Considerações sobre o design

Considere os seguintes fatores:

  • Conheça os limites do AKS. Use várias instâncias do AKS para escalar além desses limites.
  • Conheça maneiras de isolar as cargas de trabalho logicamente em um cluster e fisicamente em clusters separados.
  • Conheça maneiras de controlar o consumo de recursos por cargas de trabalho.
  • Conheça maneiras de ajudar o Kubernetes a entender a integridade de suas cargas de trabalho.
  • Esteja ciente de vários tamanhos de máquina virtual e do impacto do uso de um ou outro. VMs maiores podem lidar com mais carga. VMs menores podem ser mais fáceis de substituir por outras quando ficam indisponíveis para manutenção planejada e não planejada. Além disso, lembre-se de pools de nós e VMs em um conjunto de dimensionamento, permitindo máquinas virtuais de tamanhos diferentes no mesmo cluster. VMs maiores são mais ideais porque o AKS reserva uma porcentagem menor de seus recursos, disponibilizando mais recursos para suas cargas de trabalho.
  • Conheça maneiras de monitorar e registrar o AKS em log. O Kubernetes consiste em vários componentes, e o monitoramento e o registro em log devem fornecer insights sobre sua integridade, tendências e possíveis problemas.
  • Com base no monitoramento e registro em log, pode haver muitos eventos gerados pelo Kubernetes ou aplicativos em execução na parte superior. Os alertas podem ajudar a diferenciar entradas de log para fins de histórico e aqueles que exigem ação imediata.
  • Conheça as atualizações e os upgrades que você precisa fazer. No nível do Kubernetes, há versões principais, secundárias e de patch. O cliente deve aplicar essas atualizações para permanecer com suporte de acordo com a política no upstream Kubernetes. No nível do host de trabalho, os patches de kernel do sistema operacional podem exigir uma reinicialização, o que o cliente deve fazer e atualizar para novas versões do sistema operacional. Além de fazer upgrade manualmente de um cluster, você pode definir um canal de upgrade automático nele.
  • Esteja ciente das limitações de recursos do cluster e das cargas de trabalho individuais.
  • Conheça as diferenças entre o dimensionador automático de pod horizontal e o dimensionador automático de cluster
  • Considere proteger o tráfego entre pods usando políticas de rede e o plug-in de políticas do Azure
  • Para ajudar a solucionar problemas de aplicativos e serviços em execução no AKS, talvez seja necessário exibir os logs gerados pelos componentes do painel de controle. Talvez você queira habilitar logs de recursos para o AKS , pois o registro em log não está habilitado por padrão.

Recomendações

  • Entender os limites do AKS:

  • Use o isolamento lógico no nível do namespace para separar aplicativos, equipes, ambientes e unidades de negócios. Isolamento de multilocação e cluster. Além disso, os pools de nós podem ajudar em nós com especificações de nó diferentes e a manutenção como o Kubernetes atualiza vários pools de nós

  • Planejar e aplicar cotas de recursos no nível do namespace. Se os pods não definem limites e solicitações de recursos, rejeite a implantação usando políticas e assim por diante. Isso não se aplica a pods kube-system, pois nem todos os pods do kube-system têm solicitações e limites. Monitorare o uso de recursos e ajuste as cotas conforme necessário. Recursos básicos do agendador

  • Adicione investigações de integridade aos seus pods. Verifique se os pods contêm livenessProbe, readinessProbe e startupProbeinvestigações de integridade do AKS.

  • Use tamanhos de VM grandes o suficiente para conter várias instâncias de contêiner, para que você obtenha os benefícios do aumento da densidade, mas não tão grande que o cluster não possa lidar com a carga de trabalho de um nó com falha.

  • Use uma solução de monitoramento. Os insights de contêiner do Azure Monitor são configurados por padrão e fornecem acesso fácil a muitos insights. Use a integração do Prometheus se quiser fazer uma busca detalhada ou tiver experiência com o uso do Prometheus. Se você quiser executar um aplicativo de monitoramento no AKS, também deverá usar o Azure Monitor para monitorar esse aplicativo.

  • Use alertas de métrica de insights de contêiner do Azure Monitor para fornecer notificações quando as coisas precisarem de ação direta.

  • Use o recurso de dimensionamento automático do pool de nós junto com o dimensionador automático de pod horizontal para atender às demandas de aplicativos e para reduzir as cargas de horários de pico.

  • Use o Assistente do Azure para obter recomendações de melhores práticas sobre custo, segurança, confiabilidade, excelência operacional e desempenho. Além disso, use Microsoft Defender para Nuvem para evitar e detectar ameaças como vulnerabilidades de imagem.

  • Use o Kubernetes habilitado para Azure Arc para gerenciar clusters kubernetes não AKS no Azure usando Azure Policy, Defender para Nuvem, GitOps e assim por diante.

  • Use solicitações e limites de pod para gerenciar os recursos de computação em um cluster do AKS. Solicitações e limites de pod informam o agendador do Kubernetes sobre quais recursos de computação atribuir a um pod.

Continuidade dos negócios/recuperação de desastre para proteger e recuperar o AKS

Sua organização precisa criar recursos no nível de plataforma do Azure Kubernetes Service (AKS) adequados para atender aos requisitos específicos. Esses serviços de aplicativo têm requisitos relacionados ao RTO (objetivo de tempo de recuperação) e ao RPO (objetivo de ponto de recuperação). Há várias considerações a fazer para a recuperação de desastre do AKS. Sua primeira etapa é definir um SLA (Contrato de Nível de Serviço) para sua infraestrutura e aplicativo. Saiba mais sobre o SLA para Serviço de Kubernetes do Azure (AKS). Confira a seção Detalhes do SLA para obter informações sobre cálculos mensais de tempo de atividade.

Considerações sobre o design

Considere os seguintes fatores:

  • O cluster do AKS deve usar vários nós em um pool de nós para fornecer o nível mínimo de disponibilidade para o seu aplicativo.

  • Defina solicitações e limites de pod. Definir esses limites permite que o Kubernetes:

    • Forneça com eficiência recursos de CPU e memória aos pods.
    • Tenha densidade de contêiner mais alta em um nó.

    Os limites também podem aumentar a confiabilidade com custos reduzidos devido ao melhor uso do hardware.

  • Adequação do AKS para Zonas de Disponibilidade ou conjuntos de disponibilidade.

    • Escolha uma região que oferece suporte às Zonas de Disponibilidade.
    • As Zonas de Disponibilidade só podem ser definidas quando o pool de nós é criado e não pode ser alterado posteriormente. O suporte a várias zonas se aplica apenas a pools de nós.
    • Para o benefício zonal completo, todas as dependências de serviço também devem dar suporte às zonas. Se um serviço dependente não der suporte a zonas, uma falha de zona poderá fazer com que esse serviço falhe.
    • Execute vários clusters do AKS em diferentes regiões emparelhadas para maior disponibilidade além do que Zonas de Disponibilidade pode alcançar. Se um recurso do Azure der suporte à redundância geográfica, forneça o local em que o serviço redundante tem sua região secundária.

  • Você deve conhecer as diretrizes para recuperação de desastre no AKS. Depois, veja se elas se aplicam aos clusters do AKS que você usa para o Azure Dev Spaces.

  • Crie consistentemente backups para aplicativos e dados.

    • Um serviço sem estado pode ser replicado de forma eficiente.
    • Se você precisar armazenar o estado no cluster, fazer o back-up dos dados que estão com frequência na região emparelhada. Uma consideração é que armazenar corretamente o estado no cluster pode ser complicado.

  • Atualização e manutenção do cluster.

    • Sempre mantenha o cluster atualizado.
    • Esteja ciente do processo de nova versão e descontinuação.
    • Planeje suas atualizações e manutenção.

  • Conectividade de rede se ocorrer um failover.

    • Escolha um roteador de tráfego que possa distribuir o tráfego em diferentes zonas ou regiões, dependendo de suas necessidades. Essa arquitetura implanta o Azure Load Balancer porque pode distribuir o tráfego que não é da Web nas diferentes zonas.
    • Se você precisar distribuir o tráfego em diferentes regiões, considere usar o Azure Front Door.

  • Failovers planejados e não planejados.

    • Ao configurar cada serviço do Azure, escolha os recursos que dão suporte à recuperação de desastre. Por exemplo, essa arquitetura permite Registro de Contêiner do Azure para replicação geográfica. Você ainda poderá efetuar pull de imagens da região replicada se uma região ficar inativa.

  • Mantenha os recursos de DevOps de engenharia para atingir as metas de nível de serviço.

  • Determine se você precisa de um SLA com suporte financeiro para seu ponto de extremidade do servidor de API do Kubernetes.

Recomendações sobre design

Veja a seguir as melhores práticas para seu design:

  • Use três nós para o pool de nós do sistema. Para o pool de nós do usuário, comece com no mínimo dois nós. Se você precisar de maior disponibilidade, configure mais nós.

  • Coloque seu aplicativo em um pool de nós separado para isolá-lo dos serviços do sistema. Assim, os serviços do Kubernetes são executados em nós dedicados e não competem com outros serviços. Use marcas, rótulos e taints para identificar o pool de nós a fim de agendar sua carga de trabalho.

  • A manutenção regular do cluster, por exemplo, fazer atualizações oportunas, é crucial para a confiabilidade. Esteja atento à janela de suporte para versões do Kubernetes no AKS e planeje suas atualizações. Além disso, recomenda-se monitorar a saúde dos pods por meio de investigações.

  • Sempre que possível, remova o estado do serviço de dentro dos contêineres. Em vez disso, use uma PaaS (plataforma como serviço) do Azure que dá suporte à replicação em várias regiões.

  • Garanta o atendimento dos recursos do pod. É altamente recomendado que as implantações especifiquem requisitos de recursos do pod. O agendador pode agendar o pod adequadamente. A confiabilidade se deprecia quando os pods não são agendados.

  • Configure várias réplicas na implantação para lidar com interrupções como falhas de hardware. Para eventos planejados, como atualizações e atualizações, um orçamento de interrupção pode garantir que o número necessário de réplicas de pod exista para lidar com a carga de aplicativo esperada.

  • Os aplicativos podem usar o Armazenamento do Microsoft Azure para os dados. Como seus aplicativos estão distribuídos em vários clusters do AKS em regiões diferentes, você deve manter o armazenamento sincronizado. Seguem duas maneiras comuns de replicar o armazenamento:

    • Replicação assíncrona baseada em infraestrutura
    • Replicação assíncrona baseada em aplicativo

  • Estime os limites de pod. Teste e estabeleça uma linha de base. Comece com valores iguais para solicitações e limites. Em seguida, ajuste gradualmente os valores até que você tenha estabelecido um limite que pode causar instabilidade no cluster. Os limites de pod podem ser especificados em seus manifestos de implantação.

    Os recursos integrados fornecem uma solução para a tarefa complexa de lidar com as falhas e interrupções na arquitetura de serviço. Essas configurações ajudam a simplificar a automação de design e de implantação. Quando uma organização tiver definido um padrão para o SLA, o RTO e o RPO, ela poderá usar serviços integrados para o Kubernetes e o Azure a fim de atingir suas metas de negócios.

  • Defina os orçamentos de interrupção do pod. Essa configuração verifica quantas réplicas em uma implantação você pode desativar durante um evento de atualização ou de evento.

  • Impor cotas de recursos nos namespaces de serviço. A cota de recursos em um namespace garante que as solicitações e os limites do pod sejam definidos corretamente em uma implantação.

    • Definir cotas de recursos no nível do cluster pode causar problemas ao implantar serviços de parceiros que não têm solicitações e limites adequados.

  • Armazene as imagens de contêiner no Registro de Contêiner do Azure e faça a replicação geográfica do registro para cada região AKS.

  • Use o SLA de tempo de atividade para habilitar um SLA mais alto e com respaldo financeiro para todos os clusters que hospedam cargas de trabalho de produção. O SLA de tempo de atividade garante 99,95% de disponibilidade do ponto de extremidade do servidor de API do Kubernetes para clusters que usam Zona de Disponibilidade e 99,9% da disponibilidade para clusters que não usam Zonas de Disponibilidade. Seus nós, pools de nós e outros recursos são cobertos pelo SLA. O AKS oferece uma camada gratuita com um SLO (objetivo de nível de serviço) de 99,5% para seus componentes do painel de controle. Clusters sem o SLA de tempo de atividade habilitado não devem ser usados para cargas de trabalho de produção.

  • Use várias regiões e locais de emparelhamento para a conectividade do Azure ExpressRoute.

    Se ocorrer uma interrupção que afete uma região do Azure ou local do provedor de emparelhamento, uma arquitetura de rede híbrida redundante poderá ajudar a garantir a conectividade interlocal ininterrupta.

  • Regiões de interconexão com emparelhamento de rede virtual global. Se os clusters precisarem se comunicar entre si, a conexão de ambas as redes virtuais entre si pode ser feita por meio do emparelhamento de rede virtual. Essa tecnologia interconecta redes virtuais entre si, fornecendo alta largura de banda na rede de backbone da Microsoft, mesmo em diferentes regiões geográficas.

  • Usando o protocolo anycast baseado em TCP de divisão, o Azure Front Door garante que seus usuários finais se conectem imediatamente ao ponto de presença do Front Door mais próximo. Outros recursos do Azure Front Door incluem:

    • Encerramento de TLS
    • Domínio personalizado
    • Firewall do Aplicativo Web
    • Reconfiguração de URL
    • Afinidade de sessão

    Examine as necessidades de seu tráfego de aplicativo para saber qual é a solução mais adequada.