Boas práticas para desempenho e escalabilidade para cargas de trabalho grandes no Azure Kubernetes Service (AKS)

Ao implantar e manter clusters no AKS, você pode usar as seguintes práticas recomendadas para ajudá-lo a otimizar o desempenho e o dimensionamento.

Lembra-te que grande é um termo relativo. O Kubernetes tem um envelope de escala multidimensional, e o envelope de escala para a tua carga de trabalho depende dos recursos que utilizas. Por exemplo, um cluster com 100 nós e milhares de pods ou CRDs pode ser considerado grande. Um cluster de 1.000 nós com 1.000 pods e vários outros recursos pode ser considerado pequeno do ponto de vista do plano de controlo. O melhor sinal para a escala de um plano de controlo Kubernetes é a taxa de sucesso e latência dos pedidos HTTP do servidor API, pois isso é um proxy para a quantidade de carga no plano de controlo.

Neste artigo, você aprende sobre:

Escalabilidade do plano de controlo do AKS e Kubernetes

No AKS, um cluster consiste num conjunto de nós (máquinas físicas ou virtuais (VMs)) que executam agentes Kubernetes e são geridos pelo plano de controlo Kubernetes alojado pelo AKS. Embora o AKS otimize o plano de controlo Kubernetes e os seus componentes para escalabilidade e desempenho, continua sujeito às limitações do projeto original.

O Kubernetes tem um envelope de escala multidimensional, com cada tipo de recurso a representar uma dimensão. Nem todos os recursos são iguais. Por exemplo, os relógios são frequentemente definidos em segredos, o que resulta em chamadas de lista para o kube-apiserver, o que acrescenta custo e uma carga desproporcionalmente maior no plano de controlo em comparação com recursos sem relógios.

O plano de controlo gere toda a escalabilidade de recursos no cluster, por isso quanto mais escalares o cluster dentro de uma dada dimensão, menos podes escalar dentro de outras dimensões. Por exemplo, operar centenas de milhares de pods num cluster AKS afeta a taxa de rotação de pods (mutações de pod por segundo) que o plano de controlo consegue suportar.

O tamanho do envelope é proporcional ao tamanho do plano de controlo de Kubernetes. O AKS suporta três níveis de plano de controlo como parte do SKU Base: Livre, Standard e Premium. Para mais informações, consulte os escalões de preços Livres, Padrão e Premium para gestão de clusters AKS.

Na maioria dos casos, ultrapassar o limiar do limite de escala resulta numa degradação do desempenho, mas não faz com que o cluster faça failover imediatamente. Para gerir a carga no plano de controlo Kubernetes, considere escalar em lotes de até 10-20% da escala atual. Por exemplo, para um cluster de 5.000 nós, escale em incrementos de 500-1.000 nós. Embora o AKS escale automaticamente o teu plano de controlo, não acontece instantaneamente.

Pode aproveitar a Prioridade e Justiça da API (APF) para limitar clientes específicos e tipos de pedidos para proteger o plano de controlo durante alta rotatividade e carga.

Clientes Kubernetes

Os clientes Kubernetes são os clientes de aplicação, como operadores ou agentes de monitorização, implantados no cluster Kubernetes que precisam de comunicar com o servidor kube-api para realizar operações de leitura ou mutação. É importante otimizar o comportamento destes clientes para minimizar a carga que adicionam ao servidor kube-api e ao plano de controlo Kubernetes.

Pode analisar o tráfego do servidor API e o comportamento dos clientes através dos registos de auditoria do Kube. Para mais informações, veja Solucionar problemas no plano de controlo Kubernetes.

Os pedidos de LIST podem ser caros. Ao trabalhar com listas que possam conter mais do que alguns milhares de objetos pequenos ou mais de algumas centenas de objetos grandes, deve considerar as seguintes diretrizes:

• Considere o número de objetos (CRs) que espera que existam eventualmente ao definir um novo tipo de recurso (CRD).
• A carga no etcd e no servidor API depende principalmente do tamanho da resposta. Mesmo que use um seletor de campos para filtrar a lista e obter apenas um pequeno número de resultados, estas diretrizes continuam a aplicar-se. A única exceção é a recuperação de um único objeto por metadata.name.
• Evite chamadas LIST repetidas, se possível , caso o seu código precise de manter uma lista atualizada de objetos na memória. Em vez disso, considere usar as classes Informer fornecidas na maioria das bibliotecas Kubernetes. Os informadores combinam automaticamente as funcionalidades LIST e WATCH para manter eficientemente uma coleção em memória.
• Considere se precisa de uma forte consistência caso os Informadores não satisfaçam as suas necessidades. Precisa de ver os dados mais recentes, até ao momento exato em que emitiu a consulta? Se não, defina ResourceVersion=0. Isto faz com que a cache do servidor API sirva o seu pedido em vez de etcd.
• Se não conseguires usar Informers ou a cache do servidor API, lê listas grandes em blocos.
• Evite anunciar mais vezes do que o necessário. Se não puder usar o Informers, considere com que frequência a sua candidatura lista os recursos. Depois de leres o último objeto de uma lista grande, não voltes imediatamente a consultar a mesma lista. Deves esperar um pouco em vez disso.
• Adicione esperas exponenciais apropriadas e políticas de tentativas de repetição para impedir que os clientes sobrecarreguem o servidor da interface de programação de aplicações.
• Considere o número de instâncias em execução da sua aplicação cliente. Há uma grande diferença entre ter um único controlador a listar objetos e ter pods em cada nó fazendo a mesma coisa. Se planeia ter várias instâncias da sua aplicação cliente a listar periodicamente grandes quantidades de objetos, a sua solução não irá escalar para grandes clusters.
• Mantenha o tamanho geral do Etcd pequeno e não use o Etcd como base de dados regular. Algumas técnicas de redução do tamanho do objeto estão listadas abaixo
  • Para reduzir os tamanhos das especificações dos pods, mova variáveis de ambiente das especificações dos pods para os ConfigMaps
  • Divida grandes segredos ou ConfigMaps em partes menores e mais geríveis
  • Revise e otimize as especificações de recursos nas suas aplicações
  • Reduzir o número de revisões

Controlo de largura de banda da API e da Plataforma Azure

A carga de carga numa aplicação na cloud pode variar ao longo do tempo com base em fatores como o número de utilizadores ativos ou os tipos de ações que os utilizadores realizam. Se os requisitos de processamento do sistema excederem a capacidade dos recursos disponíveis, o sistema pode ficar sobrecarregado e sofrer de baixo desempenho e falhas.

Para lidar com diferentes tamanhos de carga numa aplicação cloud, pode permitir que a aplicação utilize recursos até um limite especificado e depois limitá-los quando o limite for atingido. No Azure, o throttling acontece em dois níveis. O Azure Resource Manager (ARM) limita os pedidos para a subscrição e o locatário. Se o pedido estiver dentro dos limites de limitação para a subscrição e o tenant, o Azure Resource Manager (ARM) encaminha o pedido para o fornecedor de recursos. O fornecedor de recursos aplica então limites de limitação adaptados às suas operações. Para mais informações, consulte pedidos de limitação do ARM.

Gerir a gestão de limitação no ambiente AKS

Os limites da API do Azure são normalmente definidos ao nível de combinação de subscrição-região. Por exemplo, todos os clientes dentro de uma subscrição numa dada região partilham limites de API para uma determinada API Azure, como as APIs PUT de Virtual Machine Scale Sets. Cada cluster AKS tem vários clientes pertencentes ao AKS, como fornecedores de cloud ou autoscaler de cluster, ou clientes pertencentes aos clientes, como Datadog ou Prometheus auto-hospedado, que chamam APIs do Azure. Ao executar múltiplos clusters AKS numa subscrição dentro de uma determinada região, todos os clientes do AKS e clientes próprios do cliente dentro dos clusters partilham um conjunto comum de limites de API. Portanto, o número de clusters que pode implementar numa região de subscrição depende do número de clientes implementados, dos seus padrões de chamadas e da escala e elasticidade global dos clusters.

Tendo em conta estas considerações, os clientes normalmente conseguem implementar entre 20 a 40 clusters de pequena e média escala por região de subscrição. Pode maximizar a sua escala de subscrição usando as seguintes melhores práticas:

Atualize sempre os seus clusters Kubernetes para a versão mais recente. As versões mais recentes contêm muitas melhorias que resolvem problemas de desempenho e limitação. Se estiveres a usar uma versão atualizada do Kubernetes e ainda veres limitação devido à carga real ou ao número de clientes na subscrição, podes experimentar as seguintes opções:

• Analise erros usando o AKS Diagnose and Solve Problems: Pode usar o AKS Diagnose and Solve Problems para analisar erros, identificar a causa raiz e obter recomendações de resolução.
  • Aumentar o intervalo de varrimento do Cluster Autoscaler: Se os relatórios de diagnóstico mostrarem que foi detetado throttling do Cluster Autoscaler, pode aumentar o intervalo de varrimento para reduzir o número de chamadas para Conjuntos de Escala de Máquinas Virtuais a partir do Cluster Autoscaler.
  • Reconfigurar aplicações de terceiros para fazer menos chamadas: Se filtrar por agentes utilizadores no diagnóstico de taxa de pedidos e redução de velocidade View e vir que uma aplicação de terceiros, como uma aplicação de monitorização, faz um grande número de pedidos GET, pode alterar as definições dessas aplicações para reduzir a frequência das chamadas GET. Certifique-se de que os clientes de aplicações usam o backoff exponencial ao chamar APIs do Azure.
• Divida os seus clusters em diferentes subscrições ou regiões: Se tiver um grande número de clusters e pools de nós que utilizam Virtual Machine Scale Sets, pode dividi-los em diferentes subscrições ou regiões dentro da mesma subscrição. A maioria dos limites de API do Azure são partilhados ao nível de subscrição-região, por isso pode mover ou escalar os seus clusters para diferentes subscrições ou regiões para superar a limitação da API do Azure. Esta opção é especialmente útil se esperares que os teus clusters tenham alta atividade. Não existem diretrizes genéricas para estes limites. Se quiser orientação específica, pode criar um pedido de suporte.

Monitorize as métricas e registos do Plano de Controlo AKS

Monitorizar métricas de plano de controlo em grandes clusters AKS é crucial para garantir a estabilidade e o desempenho das cargas de trabalho Kubernetes. Estas métricas fornecem visibilidade sobre a saúde e o comportamento de componentes críticos como o servidor API, etcd, gestor de controladores e agendador. Em ambientes de grande escala, onde a contenção de recursos e o elevado volume de chamadas de API são comuns, monitorizar métricas do plano de controlo ajuda a identificar gargalos, detetar anomalias e otimizar o uso de recursos. Ao analisar estas métricas, os operadores podem resolver proativamente questões como latência do servidor API, objetos etcd elevados ou consumo excessivo de recursos no plano de controlo, garantindo uma operação eficiente do cluster e minimizando o tempo de inatividade.

O Azure Monitor oferece métricas e registos abrangentes sobre a saúde do plano de controlo através do Azure Managed Prometheus e das definições de diagnóstico

• Para uma lista de alertas a configurar para o estado do plano de controlo, consulte Melhores práticas para monitorização do plano de controlo do AKS
• Para obter a lista de agentes utilizador com a maior latência, pode usar os registos do Plano de Controlo/Definições de Diagnóstico

Limitações de funcionalidades

Ao escalar os seus clusters AKS para pontos de escala maiores, tenha em mente as seguintes limitações de funcionalidades:

• O AKS permite escalar até 5.000 nós por padrão para todos os clusters Standard Tier / LTS. O AKS escala o plano de controlo do seu cluster em tempo de execução com base no tamanho do cluster e na utilização dos recursos do servidor API. Se não conseguires escalar até ao limite suportado, ativa as métricas do plano de controlo (Preview) com o serviço gerido Azure Monitor para o Prometheus monitorizar o plano de controlo. Para ajudar a resolver problemas de desempenho de escalabilidade ou fiabilidade, consulte os seguintes recursos:
  • Guia de resolução de problemas do AKS à escala
  • Resolver problemas do plano de controlo do Kubernetes

• O Azure Network Policy Manager (Azure npm) só suporta até 250 nós.
• Algumas métricas de nós do AKS, incluindo o uso de disco do nó, o uso de CPU/memória do nó e a entrada e saída de rede, não estarão acessíveis nas métricas da plataforma de monitorização Azure depois de o plano de controlo ser ampliado. Para confirmar se o seu plano de controlo foi expandido, procure o configmap denominado 'large-cluster-control-plane-scaling-status'

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

• Não podes usar a funcionalidade Stop and Start com clusters que têm mais de 100 nós. Para mais informações, consulte Parar e iniciar um cluster AKS.

Rede

À medida que escala os seus clusters AKS para pontos de maior escala, tenha em mente as seguintes melhores práticas de rede:

• Use o NAT Gerido para saída de cluster com pelo menos dois IPs públicos no gateway NAT. Para mais informações, consulte Criar um gateway NAT gerido para o seu cluster AKS.
• Use o Azure CNI Overlay para escalar até 200.000 pods e 5.000 nós por cluster. Para mais informações, consulte Configurar a rede Azure CNI Overlay no AKS.
• Se a sua aplicação precisar de comunicação direta pod-a-pod entre clusters, use o Azure CNI com alocação dinâmica de IP e escale até 50.000 pods de aplicação por cluster com um IP roteável por pod. Para mais informações, consulte Configurar a rede Azure CNI para alocação dinâmica de IP no AKS.
• Ao utilizar serviços Kubernetes internos atrás de um balanceador de carga interno, recomendamos criar um balanceador de carga interno ou serviço abaixo de uma escala de 750 nós para um desempenho de escalabilidade ótimo e elasticidade do balanceador de carga.
• O Azure npm só suporta até 250 nós. Se quiser aplicar políticas de rede para clusters maiores, considere usar o Azure CNI alimentado pela Cilium, que combina o plano de controlo robusto do Azure CNI com o plano de dados da Cilium para fornecer redes e segurança de alto desempenho.

Dimensionamento de grupos de nós

À medida que escalas os teus clusters AKS para uma escala maior, considera as seguintes boas práticas de escalabilidade de pools de nós:

• Para pools de nós do sistema, utilize o SKU Standard_D16ds_v5 ou um SKU de VM equivalente de núcleo/memória com discos efémeros de sistema operativo, para fornecer recursos de computação suficientes para os pods do sistema kube.
• Como o AKS tem um limite de 1.000 nós por pool de nós, recomendamos criar pelo menos cinco pools de nós de usuário para aumentar até 5.000 nós.
• Ao executar clusters AKS em grande escala, utilize o autoescalador de clusters sempre que possível para garantir uma escalabilidade dinâmica dos pools de nós com base na procura de recursos de computação. Para mais informações, consulte Escalar automaticamente um cluster AKS para satisfazer as necessidades da aplicação.
• Se estiver a escalar para além dos 1.000 nós e não estiver a usar o escalador automático do cluster, recomendamos escalar em lotes de 500-700 nós de cada vez. As operações de escalabilidade devem ter um tempo de espera de dois a cinco minutos entre operações de escalonamento para evitar limitação da API do Azure. Para mais informações, consulte gestão de APIs: Cache e políticas de limitação.

Considerações e melhores práticas sobre a atualização do cluster

• Quando um cluster atinge o limite de 5.000 nós, as atualizações do cluster são bloqueadas. Este limite impede uma atualização porque não existe capacidade disponível do nó para realizar atualizações contínuas dentro do limite máximo da propriedade de surto. Se tiver um cluster neste limite, recomendamos reduzir o cluster para menos de 3.000 nós antes de tentar uma atualização do cluster. Isto proporcionará capacidade extra para a oscilação de nós e minimizará a carga sobre o plano de controlo.
• Ao atualizar clusters com mais de 500 nós, recomenda-se usar uma configuração de aumento máximo de 10-20% da capacidade do conjunto de nós. O AKS configura as atualizações com um valor padrão de 10% para o aumento máximo. Pode personalizar as definições de aumento máximo por pool de nós para permitir um equilíbrio entre a velocidade de atualização e a afetação das cargas de trabalho. Quando aumentas as definições de surto máximo, o processo de atualização termina mais rapidamente, mas podes experienciar interrupções durante o processo. Para obter mais informações, consulte Personalizar atualização de aumento de nó.
• Para mais informações sobre a atualização do cluster, consulte Atualizar um cluster AKS.