Melhores 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:

Escalonamento de nós

Ao escalar os seus clusters AKS para pontos de escala maiores, tenha em mente as seguintes melhores práticas de escalabilidade de nós:

• Ao executar clusters AKS em escala, utilize o autoescalador de clusters ou o auto-provisionamento de nós sempre que possível para garantir a escalabilidade dinâmica dos nós com base na procura de recursos de computaçã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.
• 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.

Escalabilidade do plano de controlo do AKS e Kubernetes

No Kubernetes, todos os objetos a correr num cluster são geridos pelo plano de controlo, que é gerido 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, e nem todos os recursos são iguais em custo. Por exemplo, os Secrets são frequentemente observados por múltiplos controladores e pods, cada um dos quais faz uma chamada inicial do tipo LIST para sincronizar o estado. Como os segredos são tipicamente grandes e frequentemente atualizados, colocam mais carga no plano de controlo do que os recursos menos frequentemente visualizados.

Quanto mais escalas o aglomerado dentro de uma dada dimensão, menos consegues 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 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.

Para confirmar se o seu plano de controlo foi ampliado, procure o configmap large-cluster-control-plane-scaling-status.

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

Considerações sobre os limites de escala e o plano de controle do Kubernetes

Os clientes Kubernetes são componentes de aplicação, como operadores ou agentes de monitorização, que funcionam no cluster e comunicam com o kube-apiserver para ler ou modificar recursos. É importante otimizar o comportamento destes clientes para reduzir a carga que colocam no kube-apiserver e no plano de controlo Kubernetes.

O número de pedidos que estão a ser processados ativamente pelo servidor da API em qualquer momento é determinado por --max-requests-inflight e --max-mutating-requests-inflight sinalizadores. O AKS utiliza os valores padrão de 400 e 200 pedidos para estas bandeiras, permitindo que um total de 600 pedidos sejam despachados num dado momento. À medida que escalamos o servidor API para tamanhos maiores, aumentamos também os pedidos em voo.

Dois tipos de objetos Kubernetes, PriorityLevelConfiguration e FlowSchema (APF), determinam como o servidor API divide a capacidade total de pedidos entre os tipos de pedidos. O AKS usa a configuração padrão.

A cada PriorityLevelConfiguration é atribuída uma quota do total de pedidos permitidos. Para visualizar os objetos PriorityLevelConfiguration no seu cluster e as suas partilhas de pedidos alocadas, execute o seguinte comando.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

O FlowSchema mapeia as solicitações do servidor API a uma PriorityLevelConfiguration. Se múltiplos objetos FlowSchema corresponderem a um pedido, o servidor API seleciona aquele com a precedência correspondente mais baixa.

O mapeamento dos FlowSchemas para o PriorityLevelConfigurations pode ser visualizado usando este comando:

kubectl get flowschemas

Para confirmar se algum pedido está a ser abandonado devido ao APF, execute o seguinte comando:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Melhores práticas para clientes Kubernetes

As chamadas LIST emitidas por clientes não otimizados são frequentemente um dos maiores fatores que limitam a escalabilidade de um cluster. 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. Esta orientação aplica-se quer o cliente emita um pequeno número de pedidos LIST para objetos grandes ou um grande número de pedidos LIST para objetos mais pequenos.

Usar informadores

• Se o seu código precisar de manter uma lista atualizada de objetos em memória, usar um informador da biblioteca cliente-go dar-lhe-á benefícios ao observar alterações nos recursos com base em eventos, em vez de consultar as alterações. Esta é a melhor abordagem para evitar LISTs não otimizados e repetidos.

Usar cache do servidor API

• Use resourceVersion=0 para devolver resultados da cache do servidor API. Isto pode evitar que objetos sejam recolhidos do etcd, reduzindo assim a carga do etcd, mas não suporta paginação.

  /api/v1/namespaces/default/pods?resourceVersion=0
  

Utilização eficiente da API Kubernetes

• Recomenda-se usar o argumento do relógio sempre que possível. Sem argumentos, o comportamento padrão é listar objetos. Consulte o exemplo abaixo.

  /api/v1/namespaces/default/pods?watch=true
  

  Use o relógio com um resourceVersion conjunto para ser o valor mais recente conhecido recebido da lista ou relógio anterior. Isto é tratado automaticamente no client-go. Mas verifica se estás a usar um cliente Kubernetes noutras línguas.

  /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>
  

• Se os controladores ou operadores tiverem de usar chamadas LIST, devem evitar interrogar recursos de todo o cluster sem seletores de etiquetas ou campos, especialmente em grandes clusters. Os exemplos seguintes mostram chamadas LIST otimizadas e não otimizadas.

  LISTA Otimizada:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

  LISTA não otimizada:

  /api/v1/pods
  

• Use paginação para reduzir o tamanho das respostas LIST se o cliente tiver de obter dados do etcd. O exemplo seguinte usa o argumento do limite para restringir a resposta a 100 objetos.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100
  

  Se quiseres que a LISTA continue a devolver todos os objetos pod no exemplo acima, usa o argumento continue com limit.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>
  

  Se o kubectl estiver a ser utilizado, pode aplicar diretamente o argumento --chunk-size às respostas de paginação.

  kubectl get pods -n default --chunk-size=100
  

• Se os seus controladores ou operadores usarem atualizações de arrendamento para eleição de líderes, certifique-se de que são resilientes a problemas de conectividade transitória, ajustando leaseDuration, renewDeadline, e retryPeriod que sejam ótimas para as suas cargas de trabalho. Para controladores do Kubernetes que usam eleição de líder client-go, use a seguinte fórmula:

  lease_duration > renew_deadline > retry_period
  

Conjuntos de daemons

• Há uma diferença significativa entre um único controlador que lista objetos e um DaemonSet a correr em cada nó a fazer a mesma coisa. Se várias instâncias da sua aplicação cliente listarem periodicamente um grande número de objetos, a solução não escalará bem em grandes clusters.

• Em clusters com milhares de nós, criar um novo DaemonSet, atualizar um DaemonSet ou aumentar o número de nós pode resultar numa carga elevada no plano de controlo. Se os pods DaemonSet emitirem pedidos de servidor API dispendiosos no arranque do pod, podem causar um grande uso de recursos no plano de controlo devido a um grande número de pedidos simultâneos.

• Use uma estratégia RollingUpdate para lançar novos pods DaemonSet gradualmente. Quando o template DaemonSet é atualizado, o controlador substitui os pods antigos por novos de forma controlada. Quando a estratégia de atualização contínua não está explicitamente configurada, o Kubernetes cria por defeito um RollingUpdate com maxUnavailable como 1, maxSurge como 0 e minReadySeconds como 0s. Consulte o seguinte exemplo.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• A estratégia RollingUpdate aplica-se apenas a pods DaemonSet existentes. Não limita o impacto de adicionar novos nós, o que cria pods adicionais de DaemonSets, ou de implementar DaemonSets totalmente novos.

• Para evitar que os DaemonSets emitam pedidos LIST simultâneos ao servidor API durante o arranque após a escalabilidade do nó ou novas implementações do DaemonSet, implemente jitter de arranque no ponto de entrada do contentor e configure políticas apropriadas de backoff exponencial e de retentativa para respostas 5xx ou 429, de modo a evitar a repetição de pedidos LIST de grande dimensão.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

Otimizações ETCD

• Mantenha o tamanho geral do etcd pequeno e não use o etcd como base de dados de uso geral. O AKS fornece 8 GB de armazenamento etcd por defeito, mas bases de dados etcd maiores aumentam o tempo de desfragmentação, o que pode levar a problemas de desempenho de leitura e escrita. Bases de dados etcd maiores também podem aumentar a probabilidade de problemas de fiabilidade de servidores API e etcd se um cliente não otimizado recolher frequentemente grandes quantidades de objetos do etcd. Se o tamanho da sua base de dados etcd exceder 2 GB, considere usar as técnicas de redução do tamanho do objeto listadas abaixo.
• Para reduzir os tamanhos das especificações dos pods, transfira as variáveis de ambiente das especificações dos pods para os ConfigMaps.
• Divide grandes segredos ou ConfigMaps em partes menores e mais geríveis.
• Armazene segredos em Azure Key Vault em vez de Kubernetes Secrets sempre que possível para reduzir o número de segredos armazenados em etcd.
• Limpar objetos não utilizados
  • Apaga Jobs obsoletos e Pods concluídos. Use ttlSecondsAfterFinished em Jobs para que os objetos terminados sejam removidos automaticamente.
  • Certifica-te de que os controladores definem as referências dos proprietários. Isto permite que a recolha de lixo do Kubernetes remova automaticamente objetos dependentes quando o recurso pai é eliminado.
  • Limite o histórico do CronJob definindo successfulJobsHistoryLimit e failedJobsHistoryLimit para manter apenas um pequeno número de registos de Job concluídos.
  • Reduzir o histórico de implementação. Os antigos ReplicaSets também são armazenados como objetos API. O valor predefinido é 10.
• Reduza o histórico de revisões do Helm com o argumento --history-max. Em grandes agrupamentos, mantenha-o abaixo de 5.

Monitorizar as métricas e registos do plano de controlo do 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.

Azure Monitor oferece métricas e registos abrangentes sobre a saúde do plano de controlo através de Azure Managed Prometheus e 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

Métricas principais do plano de controle da plataforma

O AKS expõe as seguintes métricas de plataforma no Azure Monitor para monitorizar a saúde do servidor API e do etcd. Estas métricas estão disponíveis sem ativar o Managed Prometheus e podem ser visualizadas diretamente no portal Azure em Métricas para o seu cluster AKS.

Métricas do API Server:

Métricas do Etcd:

Consistentemente monitorizar apiserver_cpu_usage_percentage e apiserver_memory_usage_percentage para detetar pressão de recursos no servidor API. Se etcd_database_usage_percentage for consistentemente acima de 50%, consulte a secção de Otimizações Etcd para reduzir o tamanho da base de dados. Para a lista completa de métricas disponíveis, consulte a referência de dados de monitorização do AKS.

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 (Pré-visualização) com o serviço gerido do Azure Monitor para Prometheus para 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

  Nota

  Durante a operação para escalar o plano de controlo, poderá experimentar um aumento na latência do servidor de API ou enfrentar tempos de espera até 15 minutos. Se continuares a ter problemas para escalar até ao limite suportado, abre um ticket suporte.

• Azure Network Policy Manager (Azure npm) só suporta até 250 nós.

• Algumas métricas de nós do AKS, incluindo uso de disco do nó, uso de CPU/memória do nó e entrada/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.

• 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.

Azure API e a limitação da plataforma

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 do Azure, como as APIs PUT do Conjuntos de Dimensionamento de Máquinas Virtuais. Cada cluster AKS tem vários clientes pertencentes ao AKS, como fornecedor de nuvem ou dimensionador automático de clusters, ou clientes pertencentes aos clientes, como Datadog ou Prometheus autogerido, que fazem chamadas para as APIs da 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 Diagnosticar e Resolver Problemas: Pode usar o AKS Diagnosticar e Resolver Problemas para analisar erros, identificar a causa raiz e obter recomendações de resolução.
  • Aumentar o intervalo de análise do Cluster Autoscaler: Se os relatórios de diagnóstico mostrarem que foi detetada a limitação do Cluster Autoscaler, pode aumentar o intervalo de análise para reduzir o número de chamadas aos Conjuntos de Dimensionamento de Máquinas Virtuais pelo 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ção usam 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 usam Conjuntos de Dimensionamento de Máquinas Virtuais, pode dividi-los em diferentes subscrições ou regiões dentro da mesma subscrição. A maioria dos limites da API do Azure é partilhada ao nível da região de subscrição, por isso pode mover ou escalar os seus clusters para diferentes subscrições ou regiões para serem desbloqueados no throttling 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.

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.

• Se estiver a usar o Azure Balanceador de Carga Standard, utilize pelo menos 2 Endereços IP Públicos de Saída. Considera também os limites das regras de backend do serviço do LoadBalancer ao planear clusters grandes. Os Azure Standard Load Balancers suportam até 10.000 configurações de IP backend por IP frontend. Cada tipo: O serviço LoadBalancer cria uma regra de balanceamento de carga por porta exposta e associa todos os nós do cluster ao pool backend do balanceador de carga. Por exemplo, expor 5 portas para um único serviço atingirá este limite em 2000 nós.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• 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 Overlay do Azure CNI no AKS.

• Se a sua aplicação precisar de comunicação direta pod-to-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 Configuração de redes CNI do Azure para alocação dinâmica de IP em 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 Network Policy Manager (NPM) só suporta até 250 nós. Se quiser impor políticas de rede para clusters maiores, considere usar CNI Azure alimentado por Cilium, que combina o robusto plano de controlo do Azure CNI com o plano de dados Cilium para fornecer redes e segurança de alto desempenho.

• Ative o LocalDNS nos seus pools de nós para reduzir a latência da resolução DNS e descarregar os pods CoreDNS centralizados. Em grandes clusters com elevados volumes de consulta DNS, a resolução centralizada de DNS pode tornar-se um gargalo. O LocalDNS desdobra um proxy DNS na forma de um serviço systemd em cada nó, ao resolver consultas localmente, eliminando a pressão nas tabelas conntrack e elevando as ligações para TCP para evitar condições de corrida conntrack. O LocalDNS também suporta a entrega de respostas em cache expiradas quando o DNS upstream não está disponível, aumentando a resiliência operacional em falhas transitórias. Para mais informações, consulte resolução DNS no AKS.

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 pico máximo de 10-20% da capacidade do pool 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.