Melhores práticas de desempenho e escala para cargas de trabalho grandes no AKS (Serviço de Kubernetes do Azure)

  • Artigo

Observação

Este artigo se concentra nas melhores práticas gerais para cargas de trabalho grandes. Para ver as melhores práticas específicas de cargas de trabalho pequenas e médias, confira Melhores práticas de desempenho e escala para cargas de trabalho pequenas e médias no AKS (Serviço de Kubernetes do Azure).

Ao implantar e manter clusters no AKS, use as melhores práticas a seguir para ajudar a otimizar o desempenho e a escala.

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

Neste artigo, você aprenderá sobre:

  • O AKS e o Kubernetes controlam a escalabilidade do plano.
  • Melhores práticas do cliente de Kubernetes, incluindo retirada, inspeções e paginação.
  • Limites da limitação de plataforma e de API do Azure.
  • Limitações do recurso.
  • Melhores práticas de escala de pool de nós e rede.

Escalabilidade do painel de controle do AKS e do Kubernetes

No AKS, um cluster consiste em um conjunto de nós (VMs, máquinas virtuais ou computadores físicos) que executam agentes do Kubernetes e são gerenciados pelo painel de controle do Kubernetes hospedado pelo AKS. Embora o AKS otimize o painel de controle do Kubernetes e os respectivos componentes visando a escalabilidade e o desempenho, ele ainda está associado aos limites de 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, as inspeções geralmente são definidas em segredos, o que resulta em chamadas de lista ao kube-apiserver que adicionam custo e uma carga desproporcionalmente maior no painel de controle em comparação com recursos sem inspeções.

O painel de controle gerencia toda a escala de recursos do cluster, para que quanto mais você escalar o cluster dentro de uma dimensão especificada, menos você possa escalá-lo em outras dimensões. Por exemplo, a execução de centenas de milhares de pods em um cluster do AKS afeta a quantidade de rotatividade de pod (mutações de pod por segundo) à qual o painel de controle pode dar suporte.

O tamanho do envelope é proporcional ao tamanho do painel de controle do Kubernetes. O AKS dá suporte a três níveis de plano de controle como parte do SKU Base: nível Gratuito, Padrão e Premium. Para obter mais informações, veja os níveis de preços Gratuitos, Standard e Premium para gestão de clusters 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 painel de controle do Kubernetes para dar suporte aos seguintes limites de escala:

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

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

Aproveite a APF (Prioridade e a Imparcialidade da API) para limitar clientes e tipos de solicitação específicos, a fim de proteger o painel de controle durante alta rotatividade e carga.

Clientes do Kubernetes

Os clientes do Kubernetes são os clientes de aplicativos, como operadores ou agentes de monitoramento, implantados no cluster do 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 painel de controle do Kubernetes.

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

As solicitações LIST podem ser caras. Ao trabalhar com listas que podem ter mais de alguns milhares de objetos pequenos ou mais de algumas centenas de objetos grandes, considere as seguintes diretrizes:

  • Considere o número de objetos (CRs) que você espera que existam no final ao definir um novo tipo de recurso (CRD).
  • A carga no etcd e no servidor de API depende principalmente do número de objetos existentes, não do número de objetos 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 objeto individual por metadata.name.
  • Evite fazer chamadas LIST repetidas, se possível, se o código precisar manter uma lista atualizada de objetos na memória. Em vez disso, considere o uso das classes de informador fornecidas na maioria das bibliotecas do Kubernetes. Os informadores combinam automaticamente as funcionalidades LIST e WATCH para manter com eficiência uma coleção na memória.
  • Considere se você precisa obter consistência forte caso os informadores não atendam às suas necessidades. Você precisa ver os dados mais recentes até o 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 do etcd.
  • Se você não puder usar os informadores ou o cache do servidor de API, leia listas grandes em partes.
  • Evite usar listagens com mais frequência do que o necessário. Se você não puder usar os informadores, considere a frequência com que o seu aplicativo lista os recursos. Depois de ler o último objeto em uma lista grande, não volte a consultar imediatamente a mesma lista. Aguarde algum tempo.
  • Considere o número de instâncias em execução do aplicativo cliente. Há uma grande diferença entre ter um só controlador listando objetos e ter pods em cada nó fazendo a mesma coisa. Se você pretende ter várias instâncias do aplicativo cliente listando periodicamente um grande número de objetos, sua solução não será escalada para clusters grandes.

Limitação de plataforma e de API do Azure

A carga em um aplicativo de nuvem pode variar ao longo do tempo de acordo com 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 poderá ficar sobrecarregado e sofrer com 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, limitá-los quando o limite for atingido. No Azure, a limitação ocorre em dois níveis. O ARM (Azure Resource Manager) limita as solicitações para a assinatura e o locatário. Se a solicitação estiver dentro dos limites de limitação da assinatura e do locatário, o ARM roteará a solicitação para o provedor de recursos. O provedor de recursos aplica os limites de limitação que são ajustados às operações. Para obter mais informações, confira Solicitações de limitação do ARM.

Gerenciar a limitação no AKS

Em geral, os limites de API do Azure são definidos em um nível de combinação de assinatura/região. Por exemplo, todos os clientes de uma assinatura em uma região especificada compartilham os limites de API de determinada API do Azure, como APIs PUT dos Conjuntos de Dimensionamento de Máquinas Virtuais. Cada cluster do AKS tem vários clientes de propriedade do AKS, como o provedor de nuvem ou o dimensionador automático de cluster, ou clientes de propriedade do cliente, como o Datadog ou o Prometheus auto-hospedado, que chamam as APIs do Azure. Ao executar vários clusters do AKS em uma assinatura em determinada região, todos os clientes de propriedade do AKS e de propriedade do cliente nos 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, dos padrões de chamada e da escala geral e elasticidade dos clusters.

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

Sempre atualize seus clusters do Kubernetes para a última versão. As versões mais recentes contêm muitos aprimoramentos que resolvem problemas de desempenho e limitação. Se você estiver usando uma versão atualizada do Kubernetes e ainda observar a limitação devido à carga real ou ao número de clientes na assinatura, experimente as seguintes opções:

  • Analisar erros usando o recurso Diagnosticar e Resolver Problemas do AKS: use o recurso Diagnosticar e Resolver Problemas do AKS para analisar erros, identificar a causa raiz e obter recomendações de resolução.
  • Dividir os 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áquinas Virtuais, divida-os em diferentes assinaturas ou em diferentes regiões na mesma assinatura. A maior parte dos limites de API do Azure é compartilhada na assinatura/região, ou seja, você pode mover ou escalar seus clusters para diferentes assinaturas ou regiões a fim de que sejam desbloqueados na limitação de API do Azure. Essa opção é especialmente útil se você espera que seus clusters tenham alta atividade. Não há diretrizes genéricas para esses limites. Se você desejar obter diretrizes específicas, crie um tíquete de suporte.

Limitações dos recursos

À medida que você escala seus clusters do AKS para pontos de escala maiores, tenha em mente as seguintes limitações do recurso:

Observação

Durante a operação para dimensionar o plano de controle, você poderá encontrar latência elevada do servidor de API ou tempos limite de até 15 minutos. Se você continuar tendo problemas para escalar até o limite suportado, abra um ticket de suporte.

  • O Azure npm (Azure Network Policy Manager) só dá suporte a 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 monitor do Azure após o aumento do plano de controle. 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 que tenham mais de 100 nós. Para obter mais informações, confira Parar e iniciar um cluster do AKS.

Rede

À medida que você escala seus clusters do AKS para pontos de escala maiores, tenha em mente as seguintes melhores práticas de rede:

  • Use a NAT gerenciada para uma saída de cluster com, pelo menos, dois IPs públicos no Gateway da NAT. Para obter mais informações, confira Criar um gateway da NAT gerenciada para o cluster do AKS.
  • Use a Sobreposição da CNI do Azure para escalar verticalmente até 200.000 pods e 5.000 nós por cluster. Para saber mais, confira Configurar a Sobreposição da CNI do Azure no AKS.
  • Se o aplicativo precisar de comunicação direta de pod para pod entre clusters, use a CNI do Azure com alocação de IP dinâmica e escale até 50.000 pods de aplicativo por cluster com um IP roteável por pod. Para obter mais informações, confira Configurar a rede CNI do Azure para alocação de IP dinâmica no AKS.
  • Durante o uso de serviços internos do Kubernetes com a proteção de um balanceador de carga interno, recomendamos criar um balanceador de carga interno ou um serviço abaixo de uma escala de 750 nós, a fim de obter desempenho de escala ideal e elasticidade no balanceador de carga.
  • O Azure npm só dá suporte a 250 nós. Caso deseje impor políticas de rede para clusters maiores, considere o uso da CNI do Azure da plataforma Cilium, que combina o painel de controle robusto da CNI do Azure com o plano de dados do Cilium para fornecer segurança e rede de alto desempenho.

Escala do pool de nós

À medida que você escala seus clusters do AKS para pontos de escala maiores, tenha em mente as seguintes melhores práticas de escala do pool de nós:

  • No caso dos pools de nós do sistema, use o SKU Standard_D16ds_v5 ou um SKU de VM de núcleo/memória equivalente com discos de SO efêmero para fornecer recursos de computação suficientes para os pods do kube-system.
  • 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 escalar até 5.000 nós.
  • Ao executar clusters do AKS em escala, use o dimensionador automático de cluster sempre que possível a fim de garantir o dimensionamento dinâmico de pools de nós com base na demanda por recursos de computação. Para saber mais, confira Dimensionamento automático de um cluster do AKS para atender às demandas do aplicativo.
  • Se você está escalando para além de 1.000 nós e não está usando o dimensionador automático de cluster, recomendamos fazer isso em lotes de 500-700 nós por vez. As operações de escala devem ter um tempo de espera de dois a cinco minutos entre as operações de escala vertical para impedir a limitação de API do Azure. Para obter mais informações, confira Gerenciamento de API: políticas de cache e limitação.

Considerações e melhores práticas para a atualização de clusters

  • Quando um cluster atinge o limite de 5.000 nós, as atualizações do cluster são bloqueadas. Esses limites impedem uma atualização porque não há capacidade de nó disponível para executar atualizações contínuas dentro do limite máximo da propriedade de surto. Se você tiver um cluster nesse limite, recomendamos reduzir a escala do cluster para menos de 3.000 nós antes de tentar uma atualização do cluster. Isso fornecerá capacidade extra para rotatividade de nós e minimizará a carga no plano de controle.
  • Ao atualizar clusters com mais de 500 nós, é recomendado usar uma configuração máxima de pico de 10 a 20% da capacidade do pool de nós. AKS configura atualizações com um valor padrão de 10% para pico máximo. Você pode personalizar as configurações de pico 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 máximas do aumento, o processo de atualização é concluído mais rapidamente, mas você pode enfrentar interrupções durante o processo de atualização. Para saber mais, confira Personalizar a atualização de sobretensão de nó.
  • Para saber mais, confira Atualizar um cluster do AKS.