Partilhar via

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

  • Artigo

O Kubernetes é uma tecnologia relativamente nova, em rápida evolução com um ecossistema impressionante. Como tal, pode ser difícil geri-lo e protegê-lo.

Linha de base de operações para AKS

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

Considerações de design

Considere os seguintes fatores:

  • Esteja ciente dos limites do AKS. Use várias instâncias AKS para escalar além desses limites.
  • Esteja ciente das maneiras de isolar cargas de trabalho logicamente dentro de um cluster e fisicamente em clusters separados.
  • Esteja ciente das maneiras de controlar o consumo de recursos por cargas de trabalho.
  • Esteja ciente de maneiras de ajudar o Kubernetes a entender a integridade de suas cargas de trabalho.
  • Esteja ciente de vários tamanhos de máquinas virtuais e do impacto do uso de uma ou outra. VMs maiores podem lidar com mais carga. VMs menores podem ser substituídas mais facilmente por outras quando não estão disponíveis para manutenção planejada e não planejada. Além disso, esteja ciente de pools de nós e VMs em um conjunto de escala, 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 de seus recursos para suas cargas de trabalho.
  • Esteja ciente das maneiras de monitorar e registrar AKS. O Kubernetes consiste em vários componentes, e o monitoramento e o registro em log devem fornecer informações sobre sua integridade, tendências e possíveis problemas.
  • Com base no monitoramento e registro, pode haver muitos eventos gerados pelo Kubernetes ou aplicativos em execução no topo. Os alertas podem ajudar a diferenciar entre entradas de log para fins históricos e aquelas que exigem ação imediata.
  • Esteja ciente das atualizações e upgrades que você deve fazer. No nível do Kubernetes, existem versões principais, menores e patches. O cliente deve aplicar essas atualizações para permanecer suportado de acordo com a política no Kubernetes upstream. No nível do host de trabalho, os patches do 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 atualizar manualmente um cluster, você pode definir um canal de atualização automática no cluster.
  • Esteja ciente das limitações de recursos e cargas de trabalho individuais do cluster.
  • Esteja ciente das diferenças entre o pod autoscaler horizontal e o cluster autoscaler
  • 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 do aplicativo e dos serviços executados no AKS, talvez seja necessário visualizar os logs gerados pelos componentes do plano de controle. Talvez você queira habilitar os logs de recursos para o AKS, já que o registro em log não está habilitado por padrão.

Recomendações

  • Entenda os limites do AKS:

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

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

  • Adicione sondas de saúde aos seus pods. Certifique-se de que as cápsulas contêm livenessProbe, readinessProbee startupProbe as sondas de saúde 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 seu cluster não possa lidar com a carga de trabalho de um nó com falha.

  • Utilize uma solução de monitorização. O Azure Monitor container insights é configurado por padrão e fornece acesso fácil a muitos insights. Você pode usar a integração do Prometheus se quiser aprofundar ou tiver experiência no uso do Prometheus. Se você também quiser executar um aplicativo de monitoramento no AKS, também deve usar o Azure Monitor para monitorar esse aplicativo.

  • Use alertas de métricas de insights de contêiner do Azure Monitor para fornecer notificações quando algo precisar de ação direta.

  • Use o recurso de dimensionamento automático do pool de nós em conjunto com o autoscaler horizontal do pod para atender às demandas de aplicativos e reduzir as cargas nas horas de pico.

  • Use o Azure Advisor para obter recomendações de práticas recomendadas sobre custo, segurança, confiabilidade, excelência operacional e desempenho. Além disso, use o Microsoft Defender for Cloud para prevenir e detetar ameaças como vulnerabilidades de imagem.

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

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

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

Sua organização precisa projetar recursos adequados no nível da plataforma do Serviço Kubernetes do Azure (AKS) para atender aos seus requisitos específicos. Esses serviços de aplicativos têm requisitos relacionados ao RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Há várias considerações a serem abordadas para a recuperação de desastres do AKS. Sua primeira etapa é definir um contrato de nível de serviço (SLA) para sua infraestrutura e aplicativo. Saiba mais sobre o SLA do Serviço Kubernetes do Azure (AKS). Consulte a seção de detalhes do SLA para obter informações sobre cálculos de tempo de atividade mensal.

Considerações de design

Considere os seguintes fatores:

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

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

    • Dê eficientemente recursos de CPU e memória para os pods.
    • Ter maior densidade de contêiner 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 ofereça suporte a Zonas de disponibilidade.
    • As Zonas de Disponibilidade só podem ser definidas quando o pool de nós é criado e não podem ser alteradas posteriormente. O suporte a várias zonas só se aplica a pools de nós.
    • Para obter um benefício zonal completo, todas as dependências de serviço também devem oferecer suporte a zonas. Se um serviço dependente não suportar zonas, uma falha de zona pode fazer com que esse serviço falhe.
    • Execute vários clusters AKS em diferentes regiões emparelhadas para maior disponibilidade além do que as Zonas de Disponibilidade podem alcançar. Se um recurso do Azure der suporte à redundância geográfica, forneça o local onde o serviço redundante tem sua região secundária.

  • Você deve conhecer as diretrizes para recuperação de desastres no AKS. Em seguida, considere se eles se aplicam aos clusters AKS que você usa para os Espaços de Desenvolvimento do Azure.

  • Crie backups consistentes para aplicativos e dados.

    • Um serviço sem monitoração de estado pode ser replicado de forma eficiente.
    • Se você precisar armazenar o estado no cluster, faça backup dos dados com freqüência na região emparelhada. Uma consideração é que armazenar corretamente o estado no cluster pode ser complicado.

  • Atualização e manutenção de clusters.

    • Mantenha sempre o seu cluster atualizado.
    • Esteja ciente do processo de liberação e depreciaçã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 entre zonas ou regiões, dependendo da sua necessidade. Essa arquitetura implanta o Azure Load Balancer porque ele pode distribuir tráfego não Web entre zonas.
    • Se você precisar distribuir o tráfego entre regiões, considere usar o Azure Front Door.

  • Failovers planejados e não planejados.

    • Ao configurar cada serviço do Azure, escolha recursos que ofereçam suporte à recuperação de desastres. Por exemplo, essa arquitetura habilita o Registro de Contêiner do Azure para replicação geográfica. Você ainda pode extrair 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 o ponto de extremidade do servidor da API do Kubernetes.

Recomendações de design

Seguem-se as melhores práticas para o seu desenho ou modelo:

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

  • Isole seu aplicativo dos serviços do sistema colocando-o em um pool de nós separado. Dessa forma, os serviços do Kubernetes são executados em nós dedicados e não competem com outros serviços. Use tags, rótulos e manchas para identificar o pool de nós e agendar sua carga de trabalho.

  • A manutenção regular do seu cluster, por exemplo, fazendo 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 através de sondas.

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

  • Garanta os recursos do pod. É altamente recomendável que as implantações especifiquem os requisitos de recursos do pod. O agendador pode então agendar adequadamente o pod. A confiabilidade diminui quando os pods não são programados.

  • Configure várias réplicas na implantação para lidar com interrupções, como falhas de hardware. Para eventos planejados, como atualizações e upgrades, 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 esperada do aplicativo.

  • Seus aplicativos podem usar o Armazenamento do Azure para seus dados. Como seus aplicativos estão espalhados por vários clusters AKS em regiões diferentes, você deve manter o armazenamento sincronizado. Aqui estão duas maneiras comuns de replicar o armazenamento:

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

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

    Os recursos internos fornecem uma solução para a tarefa complexa de lidar com falhas e interrupções na arquitetura de serviço. Essas configurações ajudam a simplificar a automação do projeto e da implantação. Quando uma organização define um padrão para o SLA, RTO e RPO, ela pode usar serviços internos para o Kubernetes e o Azure para atingir suas metas de negócios.

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

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

    • A definição de 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 suas imagens de contêiner no Registro de Contêiner do Azure e replique geograficamente o registro para cada região AKS.

  • Use o SLA de tempo de atividade para habilitar um SLA mais alto e com suporte 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 final do servidor de API do Kubernetes para os clusters que utilizam Zonas de Disponibilidade e 99,9% de disponibilidade para os clusters que não utilizam Zonas de Disponibilidade. Seus nós, pools de nós e outros recursos são cobertos pelo SLA. A AKS oferece um nível gratuito com um objetivo de nível de serviço (SLO) de 99,5% para seus componentes do plano 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 conectividade do Azure ExpressRoute .

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

  • Interconecte regiões com emparelhamento de rede virtual global. Se os clusters precisarem conversar entre si, conectar ambas as redes virtuais entre si pode ser alcançado por meio do emparelhamento de rede virtual. Essa tecnologia interconecta redes virtuais entre si, fornecendo alta largura de banda em toda a rede de backbone da Microsoft, mesmo em diferentes regiões geográficas.

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

    • Terminação TLS
    • Domínio personalizado
    • Firewall de Aplicações Web
    • Reescrever URL
    • Afinidade de sessão

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