Problemas comuns ao executar ou dimensionar perguntas frequentes sobre clusters aks grandes

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

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

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

Recebo um erro "insuficienteSubnetSize" ao implantar 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, expansões ou criação de pool de nós. Esse problema ocorre porque o número de IPs gratuitos na sub-rede é menor do que o resultado da seguinte fórmula:

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

Pré-requisitos

• Para escalar 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 de planejamento de sub-rede ou recriação de cluster que você faria devido ao esgotamento de IP, consulte Alocação de IP dinâmico.

Solução

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

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

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

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

4. Escorra 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 antigos.

Estou tendo falhas esporádicas de conectividade de saída por causa do esgotamento da porta SNAT

Para clusters executados em uma escala relativamente grande (mais de 500 nós), recomendamos que você use o Gateway NAT (Tradução de Endereço de Rede Gerenciada) 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ço de rede de origem) e tempo limite de conexão para entender e resolve problemas de esgotamento da porta SNAT.

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

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

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

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

2. Dimensione os pools de nós um de cada vez. Idealmente, defina cinco minutos de tempo de sono entre escalas consecutivas de 1.000. Execute o seguinte comando:

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

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

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

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

Para as configurações máximas de aumento, 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. Aumentando o valor máximo do aumento, você permite que o processo de atualização seja concluído mais cedo. No entanto, um valor grande para o aumento máximo também pode causar interrupções durante o processo de atualização.

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

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

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

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

Minha criação de serviço interno em mais de 750 nós é lenta ou falha por causa de um erro de tempo limite

Standard Load Balancer (SLB) atualizações de pool de back-end 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 ao Kubernetes do Azure para balanceador de carga com pool de back-end baseado em IP.

Solução

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

Etapa 1: Create 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 (por esse procedimento) e manter um serviço interno com balanceamento de carga em execução. Fazer isso permite adicionar mais serviços ao balanceador de carga em escala.

A criação do serviço 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 uma nova funcionalidade que permitirá que você execute serviços balanceados 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 ao 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.