Práticas recomendadas para desempenho e dimensionamento para grandes cargas de trabalho no Serviço Kubernetes do Azure (AKS)

  • Artigo

Nota

Este artigo se concentra nas práticas recomendadas gerais para grandes cargas de trabalho. Para obter práticas recomendadas específicas para cargas de trabalho pequenas e médias, consulte Práticas recomendadas de desempenho e dimensionamento para cargas de trabalho pequenas e médias no Serviço Kubernetes do Azure (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.

Tenha em mente que grande é um termo relativo. O Kubernetes tem um envelope de escala multidimensional, e o envelope de escala para sua carga de trabalho depende dos recursos que você usa. 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 controle. O melhor sinal para a escala de um plano de controle do Kubernetes é a taxa de sucesso e a latência da solicitação HTTP do servidor API, pois isso é um proxy para a quantidade de carga no plano de controle.

Neste artigo, você aprende sobre:

  • AKS e Kubernetes controlam a escalabilidade do plano.
  • Práticas recomendadas do Kubernetes Client, incluindo backoff, relógios e paginação.
  • API do Azure e limites de limitação de plataforma.
  • Limitações de recursos.
  • Práticas recomendadas de dimensionamento de rede e pool de nós.

AKS e Kubernetes controlam escalabilidade do plano

No AKS, um cluster consiste em um conjunto de nós (máquinas físicas ou virtuais (VMs)) que executam agentes do Kubernetes e são gerenciados pelo plano de controle do Kubernetes hospedado pelo AKS. Embora o AKS otimize o plano de controle do Kubernetes e seus componentes para escalabilidade e desempenho, ele ainda está limitado pelos limites do projeto upstream.

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

O plano de controle gerencia todo o dimensionamento de recursos no cluster, portanto, quanto mais você dimensionar o cluster dentro de uma determinada dimensão, menos poderá dimensionar dentro de outras dimensões. Por exemplo, executar centenas de milhares de pods em um cluster AKS afeta a taxa de churn de pod (mutações de pod por segundo) que o plano de controle pode suportar.

O tamanho do envelope é proporcional ao tamanho do plano de controle do Kubernetes. O AKS suporta três níveis de plano de controle como parte do SKU Base: Free, Standard e Premium. Para obter mais informações, consulte Níveis de preços Gratuito, Standard e Premium para gerenciamento de cluster AKS.

Importante

É altamente recomendável usar o nível Standard ou Premium para cargas de trabalho de produção ou em escala. O AKS aumenta automaticamente o plano de controle do Kubernetes para suportar os seguintes limites de escala:

  • Até 5.000 nós por cluster AKS
  • 200.000 pods por cluster AKS (com sobreposição CNI do Azure)

Na maioria dos casos, ultrapassar o limite de escala resulta em desempenho degradado, mas não faz com que o cluster faça failover imediatamente. Para gerenciar a carga no plano de controle do Kubernetes, considere o dimensionamento em lotes de até 10-20% da escala atual. Por exemplo, para um cluster de 5.000 nós, dimensione em incrementos de 500 a 1.000 nós. Embora o AKS dimensione automaticamente seu plano de controle, isso não acontece instantaneamente.

Você pode aproveitar a prioridade e equidade da API (APF) para limitar clientes específicos e tipos de solicitação para proteger o plano de controle durante alta rotatividade e carga.

Clientes Kubernetes

Os clientes Kubernetes são os clientes de aplicativos, como operadores ou agentes de monitoramento, implantados no cluster Kubernetes que precisam se comunicar com o servidor kube-api para executar operações de leitura ou mutação. É importante otimizar o comportamento desses clientes para minimizar a carga que eles adicionam ao servidor kube-api e ao plano de controle do Kubernetes.

Você pode analisar o tráfego do servidor de API e o comportamento do cliente por meio dos logs de auditoria do Kube. Para obter mais informações, consulte Solucionar problemas do plano de controle do Kubernetes.

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

  • Considere o número de objetos (CRs) que você espera que eventualmente existam ao definir um novo tipo de recurso (CRD).
  • A carga no servidor etcd e API depende principalmente do número de objetos que existem, não do número de objetos que são retornados. Mesmo que você use um seletor de campo para filtrar a lista e recuperar apenas um pequeno número de resultados, essas diretrizes ainda se aplicam. A única exceção é a recuperação de um único objeto pelo metadata.name.
  • Evite chamadas LIST repetidas, se possível , se o código precisar manter uma lista atualizada de objetos na memória. Em vez disso, considere usar as classes Informer fornecidas na maioria das bibliotecas do Kubernetes. Os informadores combinam automaticamente as funcionalidades LIST e WATCH para manter eficientemente uma coleção na memória.
  • Considere se você precisa de uma consistência forte se os informadores não atenderem às suas necessidades. Precisa de ver os dados mais recentes, até ao momento exato em que emitiu a consulta? Caso contrário, defina ResourceVersion=0. Isso faz com que o cache do servidor de API atenda sua solicitação em vez de etcd.
  • Se não for possível usar o Informers ou o cache do servidor de API, leia listas grandes em partes.
  • Evite listar com mais frequência do que o necessário. Se você não puder usar informadores, considere a frequência com que seu aplicativo lista os recursos. Depois de ler o último objeto de uma lista grande, não volte a consultar imediatamente a mesma lista. Em vez disso, deve esperar algum tempo.
  • Considere o número de instâncias em execução do seu aplicativo cliente. Há uma grande diferença entre ter um único controlador listando objetos versus ter pods em cada nó fazendo a mesma coisa. Se você planeja ter várias instâncias do seu aplicativo cliente listando periodicamente um grande número de objetos, sua solução não será dimensionada para grandes clusters.

Limitação da API e da plataforma do Azure

A carga em um aplicativo de nuvem pode variar ao longo do tempo com base em fatores como o número de usuários ativos ou os tipos de ações que os usuários executam. 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 tamanhos de carga variáveis em um aplicativo de nuvem, você pode permitir que o aplicativo use recursos até um limite especificado e, em seguida, acelere-os quando o limite for atingido. No Azure, a limitação acontece em dois níveis. O Azure Resource Manager (ARM) limita as solicitações para a assinatura e o locatário. Se a solicitação estiver abaixo dos limites de limitação para a assinatura e o locatário, o ARM roteia a solicitação para o provedor de recursos. Em seguida, o provedor de recursos aplica limites de limitação adaptados às suas operações. Para obter mais informações, consulte Solicitações de limitação ARM.

Gerencie a limitação no AKS

Os limites da API do Azure geralmente são definidos em um nível de combinação de região de assinatura. Por exemplo, todos os clientes dentro de uma assinatura em uma determinada região compartilham limites de API para uma determinada API do Azure, como APIs PUT de Conjuntos de Escala de Máquina Virtual. Cada cluster AKS tem vários clientes de propriedade do AKS, como provedor de nuvem ou autoscaler de cluster, ou clientes de propriedade do cliente, como Datadog ou Prometheus auto-hospedado, que chamam APIs do Azure. Ao executar vários clusters AKS em uma assinatura dentro de uma determinada região, todos os clientes de propriedade do AKS e de propriedade do cliente dentro dos clusters compartilham um conjunto comum de limites de API. Portanto, o número de clusters que você pode implantar em uma região de assinatura é uma função do número de clientes implantados, seus padrões de chamada e a escala geral e elasticidade dos clusters.

Tendo em mente as considerações acima, os clientes normalmente podem implantar entre 20 e 40 clusters de pequena a média escala por região de assinatura. Você pode maximizar sua escala de assinatura usando as seguintes práticas recomendadas:

Sempre atualize 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 você estiver usando uma versão atualizada do Kubernetes e ainda vir a limitação devido à carga real ou ao número de clientes na assinatura, você pode tentar as seguintes opções:

  • Analise erros usando o AKS Diagnose and Solve Problems: Você pode usar o AKS Diagnose and Solve Problems para analisar erros, identificar a causa raiz e obter recomendações de resolução.
  • Divida seus clusters em diferentes assinaturas ou regiões: se você tiver um grande número de clusters e pools de nós que usam Conjuntos de Dimensionamento de Máquina Virtual, poderá dividi-los em diferentes assinaturas ou regiões dentro da mesma assinatura. A maioria dos limites da API do Azure é compartilhada no nível da região de assinatura, para que você possa mover ou dimensionar seus clusters para diferentes assinaturas ou regiões para ser desbloqueado na limitação da API do Azure. Essa opção é especialmente útil se você espera que seus clusters tenham alta atividade. Não existem orientações genéricas para estes limites. Se você quiser orientação específica, você pode criar um tíquete de suporte.

Limitações de recursos

Ao dimensionar seus clusters AKS para pontos de maior escala, tenha em mente as seguintes limitações de recursos:

Nota

Durante a operação para dimensionar o plano de controle, você pode encontrar latência elevada do servidor de API ou tempos limite por até 15 minutos. Se você continuar a ter problemas para dimensionar até o limite suportado, abra um tíquete de suporte.

  • O Azure Network Policy Manager (Azure npm) suporta apenas até 250 nós.
  • Algumas métricas do nó AKS, incluindo o uso do disco do nó, o uso da CPU/memória do nó e a entrada/saída da rede, não estarão acessíveis nas métricas da plataforma do azure monitor depois que o plano de controle for ampliado. Para confirmar se o seu plano de controle foi ampliado, procure o configmap 'control-plane-scaling-status'
kubectl describe configmap control-plane-scaling-status -n kube-system
  • Não é possível usar o recurso Parar e Iniciar com clusters com mais de 100 nós. Para obter mais informações, consulte Parar e iniciar um cluster AKS.

Rede

Ao dimensionar seus clusters AKS para pontos de maior escala, tenha em mente as seguintes práticas recomendadas de rede:

  • Use NAT gerenciado para saída de cluster com pelo menos dois IPs públicos no gateway NAT. Para obter mais informações, consulte Criar um gateway NAT gerenciado para seu cluster AKS.
  • Use a sobreposição CNI do Azure para dimensionar até 200.000 pods e 5.000 nós por cluster. Para obter mais informações, consulte Configurar a rede de sobreposição CNI do Azure no AKS.
  • Se seu aplicativo precisar de comunicação direta de pod para pod entre clusters, use o Azure CNI com alocação dinâmica de IP e dimensione até 50.000 pods de aplicativo por cluster com um IP roteável por pod. Para obter mais informações, consulte Configurar a rede CNI do Azure para alocação dinâmica de IP no AKS.
  • Ao usar serviços Kubernetes internos por trás de um balanceador de carga interno, recomendamos a criação de um balanceador de carga interno ou serviço abaixo de uma escala de 750 nós para desempenho de dimensionamento ideal e elasticidade do balanceador de carga.
  • O Azure npm suporta apenas até 250 nós. Se você quiser impor políticas de rede para clusters maiores, considere usar o Azure CNI com tecnologia Cilium, que combina o plano de controle robusto do Azure CNI com o plano de dados Cilium para fornecer rede e segurança de alto desempenho.

Dimensionamento do pool de nós

Ao dimensionar seus clusters AKS para pontos de maior escala, tenha em mente as seguintes práticas recomendadas de dimensionamento do pool de nós:

  • Para pools de nós do sistema, use o Standard_D16ds_v5 SKU ou um SKU de VM core/memory equivalente com discos de sistema operacional efêmeros para fornecer recursos de computação suficientes para pods do sistema kube.
  • Como o AKS tem um limite de 1.000 nós por pool de nós, recomendamos a criação de pelo menos cinco pools de nós de usuário para dimensionar até 5.000 nós.
  • Ao executar clusters AKS em escala, use o autoscaler de cluster sempre que possível para garantir o dimensionamento dinâmico de pools de nós com base na demanda por recursos de computação. Para obter mais informações, consulte Dimensionar automaticamente um cluster AKS para atender às demandas de aplicativos.
  • Se você estiver dimensionando além de 1.000 nós e não estiver usando o autoscaler de cluster, recomendamos o dimensionamento em lotes de 500 a 700 nós de cada vez. As operações de dimensionamento devem ter um tempo de espera de dois a cinco minutos entre as operações de dimensionamento para evitar a limitação da API do Azure. Para obter mais informações, consulte Gerenciamento de API: políticas de cache e limitação.

Considerações e práticas recomendadas de atualização de cluster

  • Quando um cluster atinge o limite de 5.000 nós, as atualizações de cluster são bloqueadas. Esse limite impede uma atualização porque não há capacidade de nó disponível para executar atualizações contínuas dentro do limite máximo de propriedade de surto. Se você tiver um cluster nesse limite, recomendamos reduzir o cluster para menos de 3.000 nós antes de tentar uma atualização de cluster. Isso fornecerá capacidade extra para a rotatividade do nó e minimizará a carga no plano de controle.
  • 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 atualizações com um valor padrão de 10% para aumento máximo. Você pode personalizar as configurações de aumento máximo por pool de nós para permitir uma compensação entre a velocidade de atualização e a interrupção da carga de trabalho. Quando você aumenta as configurações de aumento máximo, o processo de atualização é concluído mais rapidamente, mas você pode sofrer interrupções durante o processo de atualização. Para obter mais informações, consulte Personalizar atualização de aumento de aumento de nó.
  • Para obter mais informações sobre a atualização do cluster, consulte Atualizar um cluster AKS.