Perguntas frequentes sobre problemas comuns ao executar ou dimensionar grandes clusters do AKS

  • Artigo

Este artigo responde a perguntas frequentes sobre problemas comuns que podem ocorrer quando você executa ou dimensiona clusters grandes no AKS (Serviço de Kubernetes do Microsoft Azure). Um cluster grande é qualquer cluster executado em uma escala de mais de 500 nós.

Recebo um erro de "cota excedida" durante a criação, expansão ou atualização

Para resolver esse problema, crie uma solicitação de suporte na assinatura na qual você está tentando criar, dimensionar ou atualizar e solicite uma cota para o tipo de recurso correspondente. Para obter mais informações, consulte cotas de computação regionais.

Recebo um erro "insufficientSubnetSize" quando implanto um cluster do AKS que usa rede avançada

Esse erro indica que uma sub-rede que está em uso para um cluster não tem mais IPs disponíveis em seu CIDR para atribuição de recursos bem-sucedida. Esse problema pode ocorrer durante atualizações, escalações contínuas ou criação de pool de nós. Esse problema ocorre porque o número de IPs livres na sub-rede é menor que o resultado da seguinte fórmula:

Número de nós solicitados * Valor do pool --max-pod de nós

Pré-requisitos

  • Para dimensionar além de 400 nós, você precisa usar o plug-in de rede CNI do Azure.

  • Para ajudar a planejar sua rede virtual e sub-redes para acomodar o número de nós e pods que você está implantando, consulte planejando endereços IP para seu cluster. Para reduzir a sobrecarga do planejamento de sub-rede ou da recriação de cluster que você faria devido ao esgotamento de IP, consulte Alocação de IP dinâmico.

Solução

Como não é possível atualizar o intervalo CIDR de uma sub-rede existente, você deve ter permissão para criar uma nova sub-rede para resolver esse problema. Siga estas etapas:

  1. Recrie uma nova sub-rede que tenha um intervalo CIDR maior que seja suficiente para as metas de operação.

  2. Crie uma nova sub-rede que tenha um novo intervalo não sobreposto.

  3. Crie um novo pool de nós na nova sub-rede.

  4. Drene pods do pool de nós antigo que reside na sub-rede antiga que será substituída.

  5. Exclua a sub-rede antiga e o pool de nós antigo.

Estou tendo falhas esporádicas de conectividade de saída devido ao esgotamento da porta SNAT

Para clusters executados em uma escala relativamente grande (mais de 500 nós), recomendamos que você use o Gateway NAT (Conversão de Endereços de Rede) Gerenciado do AKS para maior escalabilidade. O Gateway NAT do Azure permite até 64.512 fluxos de tráfego UDP e TCP de saída por endereço IP e um máximo de 16 endereços IP.

Se você não estiver usando o NAT gerenciado, consulte Solucionar problemas de esgotamento de SNAT (conversão de endereços de rede de origem) e tempos limite de conexão para entender e resolver problemas de esgotamento de porta SNAT.

Não consigo escalar verticalmente até 5.000 nós usando o portal do Azure

Use a CLI do Azure para escalar verticalmente até um máximo de 5.000 nós seguindo estas etapas:

  1. Crie um número mínimo de pools de nós no cluster (porque o limite máximo de nós do pool de nós é 1.000) executando o seguinte comando:

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. Escale verticalmente os pools de nós um de cada vez. Idealmente, defina cinco minutos de sono entre aumentos consecutivos de 1.000. Execute o comando a seguir:

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

Minha atualização está em execução, mas está lenta

Em sua configuração padrão, o AKS surge durante uma atualização executando as seguintes ações:

  • Criando um novo nó.
  • Dimensionar o pool de nós além do número desejado de nós por um nó.

Para as configurações de pico máximo, um valor padrão de um nó significa que o AKS cria um novo nó antes de drenar os aplicativos existentes e substituir um nó com versão anterior. Esse nó extra permite que o AKS minimize a interrupção da carga de trabalho.

Quando você atualiza clusters que têm muitos nós, pode levar várias horas para atualizar todo o cluster se você usar o valor padrão de max-surge. Você pode personalizar a max-surge propriedade por pool de nós para habilitar uma compensação entre a velocidade de atualização e a interrupção da atualização. Ao aumentar o valor máximo de surto, você permite que o processo de atualização seja concluído mais cedo. No entanto, um grande valor para o pico máximo também pode causar interrupções durante o processo de atualização.

Execute o seguinte comando para aumentar ou personalizar o pico máximo para um pool de nós existente:

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

Também é importante considerar como suas configurações de implantação podem atrasar a conclusão da operação de atualização ou dimensionamento:

Dica

Para obter mais informações sobre esse comportamento, você pode exibir detalhes do erro na página Log de Atividades no portal do Azure ou examinar os logs de recursos no cluster.

Minha atualização está atingindo o limite de cota (5.000 clusters)

Para resolver esse problema, consulte Aumentar cotas regionais de vCPU.

Minha criação de serviço interno em mais de 750 nós está lenta ou falhando devido a um erro de tempo limite

As atualizações do pool de back-end do SLB (Standard Load Balancer) são um gargalo de desempenho conhecido. Estamos trabalhando em um novo recurso que permitirá a criação mais rápida de serviços e SLB em escala. Para nos enviar seus comentários sobre esse problema, confira Suporte do Kubernetes do Azure para balanceador de carga com pool de back-end baseado em IP.

Solução

Recomendamos que você reduza o cluster para menos de 750 nós e, em seguida, crie um balanceador de carga interno para o cluster. Para criar um balanceador de carga interno, crie um tipo de serviço e azure-load-balancer-internal uma LoadBalancer anotação, de acordo com o procedimento de exemplo a seguir.

Etapa 1: Criar um balanceador de carga interno

Para criar um balanceador de carga interno, crie um manifesto de serviço chamado internal-lb.yaml e que contenha o LoadBalancer tipo de serviço e a azure-load-balancer-internal anotação, conforme mostrado no exemplo a seguir:

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

Etapa 2: Implantar o balanceador de carga interno

Implante o balanceador de carga interno usando o kubectl apply comando e especifique o nome do manifesto YAML, conforme mostrado no exemplo a seguir:

kubectl apply -f internal-lb.yaml

Depois que o cluster for criado, você também poderá provisionar um balanceador de carga interno (de acordo com este procedimento) e manter um serviço interno com balanceamento de carga em execução. Isso permite que você adicione mais serviços ao balanceador de carga em escala.

A criação de serviços SLB em escala leva horas para ser executada

As atualizações do pool de back-end do SLB são um gargalo de desempenho conhecido. Estamos trabalhando em um novo recurso que permitirá que você execute serviços de balanceamento de carga em escala com desempenho consideravelmente mais rápido para operações de criação, atualização e exclusão. Para nos enviar seus comentários, confira Suporte do Kubernetes do Azure para balanceador de carga com pool de back-end baseado em IP.

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.