Considerações de gestão de operações para Azure Kubernetes Service

  • Artigo

O Kubernetes é uma tecnologia relativamente nova, que evolui rapidamente com um ecossistema impressionante. Como tal, pode ser um desafio geri-la e protegê-la.

Linha de base de operações do AKS

Pode trabalhar no sentido da excelência operacional e do sucesso do cliente ao conceber corretamente a sua solução de Azure Kubernetes Service (AKS) com gestão e monitorização em mente.

Considerações de design

Considere os seguintes fatores:

  • Tenha em atenção os limites do AKS. Utilize várias instâncias do AKS para dimensionar para além desses limites.
  • Tenha em atenção formas de isolar as cargas de trabalho logicamente num cluster e fisicamente em clusters separados.
  • Tenha em atenção formas de controlar o consumo de recursos por cargas de trabalho.
  • Tenha em atenção formas de ajudar o Kubernetes a compreender o estado de funcionamento das suas cargas de trabalho.
  • Tenha em atenção vários tamanhos de máquinas virtuais e o impacto da utilização de um ou outro. As VMs maiores podem processar mais carga. As VMs mais pequenas podem ser substituídas por outras pessoas quando não estão disponíveis para manutenção planeada e não planeada. Além disso, tenha em atenção os conjuntos de nós e as VMs num conjunto de dimensionamento, permitindo máquinas virtuais de tamanhos diferentes no mesmo cluster. As VMs maiores são mais ideais porque o AKS reserva uma percentagem menor dos respetivos recursos, disponibilizando mais recursos para as cargas de trabalho.
  • Tenha em atenção formas de monitorizar e registar o AKS. O Kubernetes é composto por vários componentes e a monitorização e o registo devem fornecer informações sobre o seu estado de funcionamento, tendências e potenciais problemas.
  • Com base na monitorização e no registo, pode haver muitos eventos gerados pelo Kubernetes ou aplicações em execução na parte superior. Os alertas podem ajudar a diferenciar entre entradas de registo para fins históricos e aqueles que necessitam de ação imediata.
  • Tenha em atenção as atualizações e atualizações que deve fazer. Ao nível do Kubernetes, existem versões principais, secundárias e de patch. O cliente deve aplicar estas atualizações para permanecer suportado de acordo com a política no Kubernetes a montante. Ao nível do anfitrião de trabalho, os patches de kernel do SO podem exigir um reinício, o que o cliente deve fazer, e atualizar para novas versões do SO. Além de atualizar manualmente um cluster, pode definir um canal de atualização automática no cluster.
  • Tenha em atenção as limitações de recursos do cluster e as cargas de trabalho individuais.
  • Tenha em atenção as diferenças entre o dimensionador automático de pods horizontal e o dimensionador automático de clusters
  • Considere proteger o tráfego entre pods com políticas de rede e o plug-in de políticas do Azure
  • Para ajudar a resolver problemas da aplicação e dos serviços em execução no AKS, poderá ter de ver os registos gerados pelos componentes do plano de controlo. Poderá querer ativar os registos de recursos para o AKS , uma vez que o registo não está ativado por predefinição.

Recomendações

  • Compreender os limites do AKS:

  • Utilize o isolamento lógico ao nível do espaço de nomes para separar aplicações, equipas, ambientes e unidades empresariais. Isolamento de clusters e multi-inquilinos. Além disso, os conjuntos de nós podem ajudar em nós com diferentes especificações de nós e manutenção como o Kubernetes atualiza múltiplos conjuntos de nós

  • Planeie e aplique quotas de recursos ao nível do espaço de nomes. Se os pods não definirem os pedidos de recursos e os limites, rejeite a implementação com políticas e assim sucessivamente. Isto não se aplica aos pods do sistema kube, uma vez que nem todos os pods do sistema kube têm pedidos e limites. Monitorize a utilização de recursos e ajuste as quotas conforme necessário. Funcionalidades básicas do Scheduler

  • Adicione sondas de estado de funcionamento aos seus pods. Certifique-se de que os pods contêm livenessProbeas sondas de estado de funcionamento do AKS e startupProbe do readinessProbeAKS.

  • Utilize tamanhos de VM suficientemente grandes para conter várias instâncias de contentor, para que obtenha os benefícios de uma maior densidade, mas não tão grande que o cluster não consiga lidar com a carga de trabalho de um nó com falhas.

  • Utilize uma solução de monitorização. As informações de contentor do Azure Monitor estão configuradas por predefinição e proporcionam acesso fácil a muitas informações. Pode utilizar a integração do Prometheus se quiser aprofundar ou ter experiência com o Prometheus. Se também quiser executar uma aplicação de monitorização no AKS, também deve utilizar o Azure Monitor para monitorizar essa aplicação.

  • Utilize alertas de métricas do Azure Monitor Container Insights para fornecer notificações quando as coisas precisam de ação direta.

  • Utilize a funcionalidade de dimensionamento automático do conjunto de nós juntamente com o dimensionador automático de pods horizontal para satisfazer as exigências da aplicação e para mitigar as cargas de horas de ponta.

  • Utilize o Assistente do Azure para obter recomendações de melhores práticas sobre custos, segurança, fiabilidade, excelência operacional e desempenho. Além disso, utilize Microsoft Defender para a Cloud para prevenir e detetar ameaças como vulnerabilidades de imagens.

  • Utilize o Kubernetes compatível com o Azure Arc para gerir clusters do Kubernetes não AKS no Azure com Azure Policy, Defender para Cloud, GitOps, entre outros.

  • Utilize pedidos de pod e limites para gerir os recursos de computação num cluster do AKS. Os pedidos e limites do Pod informam o agendador do Kubernetes sobre os recursos de computação a atribuir a um pod.

Continuidade do negócio/recuperação após desastre para proteger e recuperar o AKS

A sua organização tem de criar capacidades adequadas ao nível da plataforma Azure Kubernetes Service (AKS) para satisfazer os requisitos específicos. Estes serviços de aplicação têm requisitos relacionados com o objetivo de tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO). Existem várias considerações a abordar para a recuperação após desastre do AKS. O primeiro passo é definir um contrato de nível de serviço (SLA) para a sua infraestrutura e aplicação. Saiba mais sobre o SLA para Azure Kubernetes Service (AKS). Veja a secção Detalhes do SLA para obter informações sobre os cálculos mensais de tempo de atividade.

Considerações de design

Considere os seguintes fatores:

  • O cluster do AKS deve utilizar vários nós num conjunto de nós para fornecer o nível mínimo de disponibilidade para a sua aplicação.

  • Defina os pedidos e limites do pod. Definir estes limites permite ao Kubernetes:

    • Atribua recursos de CPU e memória aos pods de forma eficiente.
    • Ter maior densidade de contentor num nó.

    Os limites também podem aumentar a fiabilidade com custos reduzidos devido a uma melhor utilização do hardware.

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

    • Escolha uma região que suporte Zonas de Disponibilidade.
    • Zonas de Disponibilidade só pode ser definido quando o conjunto de nós é criado e não pode ser alterado mais tarde. O suporte de multizona aplica-se apenas a conjuntos de nós.
    • Para um benefício zonal completo, todas as dependências de serviço também têm de suportar zonas. Se um serviço dependente não suportar zonas, uma falha na zona poderá fazer com que esse serviço falhe.
    • Execute vários clusters do AKS em diferentes regiões emparelhadas para uma maior disponibilidade para além do que Zonas de Disponibilidade pode alcançar. Se um recurso do Azure suportar a georredundância, indique a localização onde o serviço redundante tem a sua região secundária.

  • Deve conhecer as diretrizes para a recuperação após desastre no AKS. Em seguida, considere se se aplicam aos clusters do AKS que utiliza para o Azure Dev Spaces.

  • Crie consistentemente cópias de segurança para aplicações e dados.

    • Um serviço não com estado pode ser replicado de forma eficiente.
    • Se precisar de armazenar o estado no cluster, faça uma cópia de segurança dos dados frequentemente na região emparelhada. Uma consideração é que armazenar corretamente o estado no cluster pode ser complicado.

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

    • Mantenha sempre o cluster atualizado.
    • Tenha em atenção o processo de versão e preterição.
    • Planeie as atualizações e a manutenção.

  • Conectividade de rede se ocorrer uma ativação pós-falha.

    • Escolha um router de tráfego que possa distribuir o tráfego entre zonas ou regiões, consoante o seu requisito. Esta arquitetura implementa Balanceador de Carga do Azure porque pode distribuir tráfego não Web entre zonas.
    • Se precisar de distribuir o tráfego entre regiões, considere utilizar o Azure Front Door.

  • Ativações pós-falha planeadas e não planeadas.

    • Ao configurar cada serviço do Azure, selecione as funcionalidades que suportam a recuperação após desastre. Por exemplo, esta arquitetura permite Azure Container Registry para georreplicação. Ainda pode extrair imagens da região replicada se uma região ficar inativa.

  • Mantenha as capacidades do DevOps de engenharia para atingir os objetivos ao nível do serviço.

  • Determine se precisa de um SLA com suporte financeiro para o ponto final do servidor da API do Kubernetes.

Recomendações de conceção

Seguem-se as melhores práticas para a sua conceção:

  • Utilize três nós para o conjunto de nós do sistema. Para o conjunto de nós de utilizador, comece com nada menos do que dois nós. Se precisar de uma maior disponibilidade, configure mais nós.

  • Isole a sua aplicação dos serviços de sistema ao colocá-la num conjunto de nós separado. Desta forma, os serviços do Kubernetes são executados em nós dedicados e não competem com outros serviços. Utilize etiquetas, etiquetas e taints para identificar o conjunto de nós para agendar a carga de trabalho.

  • A manutenção regular do cluster, por exemplo, para fazer atualizações oportunas, é crucial para a fiabilidade. Tenha em atenção a janela de suporte das versões do Kubernetes no AKS e planeie as suas atualizações. Além disso, recomenda-se monitorizar o estado de funcionamento dos pods através de sondas.

  • Sempre que possível, remova o estado do serviço de contentores internos. Em vez disso, utilize uma plataforma como um serviço (PaaS) do Azure que suporte a replicação de várias regiões.

  • Confirme os recursos do pod. Recomenda-se vivamente que as implementações especifiquem os requisitos de recursos do pod. Em seguida, o agendador pode agendar adequadamente o pod. A fiabilidade deprecia quando os pods não são agendados.

  • Configure várias réplicas na implementação para lidar com interrupções como falhas de hardware. Para eventos planeados, como atualizações e atualizações, um orçamento de interrupção pode garantir que o número necessário de réplicas de pods existe para processar a carga esperada da aplicação.

  • As aplicações podem utilizar o Armazenamento do Azure para os respetivos dados. Uma vez que as aplicações estão distribuídas por vários clusters do AKS em diferentes regiões, tem de manter o armazenamento sincronizado. Seguem-se duas formas comuns de replicar o armazenamento:

    • Replicação assíncrona baseada em infraestrutura
    • Replicação assíncrona baseada na aplicação

  • Estimar limites de pods. Teste e estabeleça uma linha de base. Comece com valores iguais para pedidos e limites. Em seguida, ajuste gradualmente esses valores até estabelecer um limiar que possa causar instabilidade no cluster. Os limites do pod podem ser especificados nos seus manifestos de implementação.

    As funcionalidades incorporadas fornecem uma solução para a tarefa complexa de lidar com falhas e interrupções na arquitetura do serviço. Estas configurações ajudam a simplificar a automatização de design e implementação. Quando uma organização define um padrão para o SLA, RTO e RPO, pode utilizar serviços incorporados para o Kubernetes e o Azure para atingir os seus objetivos empresariais.

  • Definir orçamentos de interrupção do pod. Esta definição verifica quantas réplicas numa implementação pode eliminar durante um evento de atualização ou atualização.

  • Impor quotas de recursos nos espaços de nomes de serviço. A quota de recursos num espaço de nomes garante que os pedidos de pod e os limites estão corretamente definidos numa implementação.

    • Definir quotas de recursos ao nível do cluster pode causar problemas ao implementar serviços de parceiros que não têm pedidos e limites adequados.

  • Armazene as suas imagens de contentor no Azure Container Registry e replice georreplicar o registo para cada região do AKS.

  • Utilize o SLA uptime para ativar um SLA mais elevado e apoiado financeiramente para todos os clusters que alojam cargas de trabalho de produção. O SLA de tempo de atividade garante 99,95% de disponibilidade do ponto final do servidor da API do Kubernetes para clusters que utilizam Zonas de Disponibilidade e 99,9% de disponibilidade para clusters que não utilizam Zonas de Disponibilidade. Os nós, conjuntos de nós e outros recursos estão abrangidos pelo respetivo SLA. O AKS oferece um escalão gratuito com um objetivo de nível de serviço (SLO) de 99,5% para os componentes do plano de controlo. Os clusters sem o SLA de Tempo de Atividade ativado não devem ser utilizados para cargas de trabalho de produção.

  • Utilize várias regiões e localizações de peering para a conectividade do Azure ExpressRoute .

    Se ocorrer uma falha que afete uma região do Azure ou a localização do fornecedor de peering, uma arquitetura de rede híbrida redundante pode ajudar a garantir a conectividade entre locais ininterrupta.

  • Interligar regiões com peering de rede virtual global. Se os clusters precisarem de falar entre si, a ligação entre redes virtuais pode ser obtida através do peering de rede virtual. Esta tecnologia interliga redes virtuais entre si, proporcionando uma largura de banda elevada na rede principal da Microsoft, mesmo em diferentes regiões geográficas.

  • Com o protocolo anycast baseado em TCP dividido, o Azure Front Door garante que os utilizadores finais se ligam rapidamente ao ponto de presença mais próximo do Front Door. Outras funcionalidades do Azure Front Door incluem:

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

    Reveja as necessidades do tráfego da sua aplicação para saber qual é a solução mais adequada.