Resolva o código de erro SubnetIsFull durante uma atualização do cluster AKS.

Resumo

Este artigo explica como identificar e resolver o erro SubnetIsFull que ocorre quando você atualiza um cluster AKS (Serviço de Kubernetes do Azure). Ele ajuda você a concluir a atualização com êxito.

Aqui está um exemplo da mensagem de erro:

Falha ao dimensionar o pool de nós <NOME DO POOL DE AGENTES>' no serviço do Kubernetes '<NAME>'. Erro: repetição de VMSSAgentPoolReconciler falhou: Code='SubnetIsFull' Message='<NOME DA SUBREDE>\ com prefixo de endereço <PREFIX>\ não tem capacidade suficiente para endereços IP.' Detalhes=[]

Pré-requisitos

Este artigo requer a CLI do Azure versão 2.0.65 ou uma versão posterior. Para localizar o número da versão, execute az --version. Se você precisar instalar ou atualizar CLI do Azure, consulte Como instalar o CLI do Azure.

Para obter informações mais detalhadas sobre o processo de atualização, consulte a seção "Atualizar um cluster do AKS" em Atualizar um cluster do AKS (Serviço de Kubernetes do Azure).

Sintomas

Uma atualização de cluster do AKS falha e você recebe uma mensagem de erro "SubnetIsFull".

Motivo

Esse erro ocorrerá se o seu cluster não tiver endereços IP suficientes para criar um novo nó.

Ao planejar uma operação de atualização ou dimensionamento, considere o número de endereços IP necessários. Se o intervalo de endereços IP configurado no cluster oferecer suporte apenas a um número fixo de nós, a operação de atualização ou dimensionamento falhará. Para obter mais informações, consulte o planejamento de endereço IP para seus clusters do AKS (Serviço de Kubernetes do Azure).

Verificar os IPs disponíveis na sub-rede

Antes de tomar medidas corretivas, verifique quantos endereços IP estão disponíveis na sub-rede associada ao cluster do AKS.

Para verificar os endereços IP disponíveis no Azure portal:

1. Vá para o serviço de redes virtuais .
2. Selecione a rede virtual associada ao cluster do AKS.
3. No menu, selecione Sub-redes.
4. Examine a coluna IPs disponível para a sub-rede que o cluster usa.

Como alternativa, você pode executar os seguintes comandos CLI do Azure para verificar os IPs disponíveis:

# Get the subnet resource ID for the node pool.
# For clusters that use a custom VNet, the subnet ID is stored in the agent pool profile:
SUBNET_ID=$(az aks show \
    --resource-group <RESOURCE_GROUP> \
    --name <CLUSTER_NAME> \
    --query "agentPoolProfiles[0].vnetSubnetId" \
    --output tsv)

# If the cluster uses a managed VNet (SUBNET_ID is empty),
# retrieve the subnet from the node resource group instead:
if [[ -z "$SUBNET_ID" ]]; then
    NODE_RESOURCE_GROUP=$(az aks show \
        --resource-group <RESOURCE_GROUP> \
        --name <CLUSTER_NAME> \
        --query "nodeResourceGroup" \
        --output tsv)

    SUBNET_ID=$(az network vnet list \
        --resource-group "$NODE_RESOURCE_GROUP" \
        --query "[0].subnets[0].id" \
        --output tsv)
fi

# Display the subnet details and calculate available IPs
az network vnet subnet show \
    --ids "$SUBNET_ID" \
    --query "{SubnetName:name, AddressPrefix:addressPrefix, UsedIPs:length(ipConfigurations || \`[]\`)}" \
    --output json | jq -r '
    .AddressPrefix as $prefix |
    ($prefix | split("/")[1] | tonumber) as $prefixLen |
    pow(2; 32 - $prefixLen) as $totalIPs |
    5 as $reserved |
    (.UsedIPs // 0) as $used |
    ($totalIPs - $reserved - $used) as $available |
    ["SubnetName", "AddressPrefix", "TotalIPs", "UsedIPs", "AzureReserved", "AvailableIPs"],
    [.SubnetName, $prefix, ($totalIPs | tostring), ($used | tostring), ($reserved | tostring), ($available | tostring)]
    | @tsv' | column -t

A saída é semelhante ao exemplo a seguir:

SubnetName  AddressPrefix  TotalIPs  UsedIPs  AzureReserved  AvailableIPs
aks-subnet  xx.xxx.x.x/16  65536     327      5              65204

Se o número de IPs disponíveis for baixo (por exemplo, menos do que o número de nós que você está adicionando durante a atualização), prossiga com a solução na próxima seção.

Solução

Reduza os nós de cluster para reservar endereços IP para a atualização.

Se a redução de escala não for uma opção e a CIDR de rede virtual tiver endereços IP suficientes, tente adicionar um pool de nós que tenha uma sub-rede exclusiva:

1. Adicione um novo pool de nós de usuário na rede virtual em uma sub-rede maior.
2. Alterne o pool de nós original para um tipo de pool de nós do sistema.
3. Aumentar o pool de nós do usuário.
4. Reduza verticalmente o pool de nós original.

Recuperação quando o pool de nós está em estado de falha no provisionamento

Quando uma atualização falha com SubnetIsFull, o pool de nós do AKS afetado e o Conjunto de Dimensionamento de Máquinas Virtuais (VMSS) subjacente podem permanecer em um estado de provisionamento Failed. Para verificar o estado, execute:

az aks nodepool show \
    --resource-group <RESOURCE_GROUP> \
    --cluster-name <CLUSTER_NAME> \
    --name <NODEPOOL_NAME> \
    --query "provisioningState" \
    --output tsv

Depois que o pool de nós estiver nesse estado:

• As operações subsequentes no mesmo pool de nós (como az aks nodepool scale, az aks nodepool upgrade, ou tentar novamente a atualização original) não têm garantia de sucesso, mesmo depois de os endereços IP serem liberados pela redução de outros pools de nós.
• Liberar endereços IP após a falha não é, por si só, um mecanismo de recuperação confiável.

O caminho de recuperação recomendado é adicionar um novo pool de nós em uma sub-rede com capacidade de IP suficiente e mover cargas de trabalho para fora do pool com falha:

1. Adicione um novo pool de nós em uma sub-rede que tenha IPs disponíveis suficientes para o número desejado de nós e a configuração maxPods. Consulte Adicionar um pool de nós com uma sub-rede exclusiva.
2. Isole e drene as cargas de trabalho do pool de nós com falha para que sejam reagendadas para o novo pool de nós.
3. Exclua o pool de nós com falha usando az aks nodepool delete.
4. Planeje atualizações futuras usando o planejamento de endereço IP para clusters do AKS para evitar a recorrência.

Resources

• Código de erro InsufficientSubnetSize