Resolver problemas de gerenciamento de endereços IP em clusters da VPC

O gerenciamento eficaz de endereços IP é crucial para a estabilidade e a escalonabilidade dos clusters nativos de VPC do Google Kubernetes Engine (GKE). Os problemas podem impedir o escalonamento ou causar falhas na carga de trabalho, como falhas na programação de pods.

Use este documento para solucionar problemas relacionados à alocação de endereços IP, estabilidade de rede e recursos de rede avançados em clusters nativos de VPC do GKE.

Essas informações são destinadas principalmente a administradores e operadores de plataforma que gerenciam a infraestrutura de rede do cluster. Ele também ajuda os desenvolvedores de aplicativos a entender como as limitações de rede subjacentes, como o espaço de endereço IP esgotado, podem afetar as cargas de trabalho. Embora os desenvolvedores não configurem diretamente as VPCs, entender esses problemas comuns ajuda a colaborar melhor com os administradores e operadores da plataforma para resoluções mais rápidas. Para mais informações sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Tarefas e papéis de usuário comuns do GKE.

Diagnosticar o esgotamento de endereços IP

A falta de endereços IP no cluster pode impedir o escalonamento de nós e interromper as cargas de trabalho. Nesta seção, explicamos como usar o monitoramento de utilização de endereços IP no GKE para detectar e resolver possíveis problemas de esgotamento.

O GKE calcula o uso de endereços IP usando dados de insights do Network Analyzer e outras fontes de dados do GKE. Esse monitoramento está disponível para todos os clusters nativos de VPC.

Para ver a utilização do endereço IP de um cluster, faça o seguinte:

  1. No console do Google Cloud , acesse a página de clusters do Kubernetes.

    Acessar clusters do Kubernetes

  2. Clique no nome do cluster que você quer examinar. Essa ação abre a página Detalhes do cluster.

  3. Acesse a página Uso de IP usando um dos seguintes métodos:

    • Selecione a guia Observabilidade e, no menu de navegação de observabilidade, clique em Uso de IP.

    • Na seção Rede, encontre a linha Intervalo IPv4 do pod do cluster (padrão) e clique em Ver uso de IP.

  4. Consulte a coluna Status da alocação de IP. Essa coluna mostra a porcentagem de endereços IP alocados no intervalo de endereços IP do pod. O GKE considera todos os endereços IP no intervalo CIDR atribuído de um nó como alocados, independentemente de os endereços IP individuais serem atribuídos a pods. Esse comportamento significa que a porcentagem reflete todo o intervalo de pods de um nó, não apenas os endereços IP em uso. Se os clusters tiverem os mesmos intervalos de endereços IP, a porcentagem de uso vai mostrar o total combinado.

  5. Para uma visualização detalhada do uso de endereços IP, incluindo intervalos CIDR, informações de sub-rede e recomendações, clique em Mostrar detalhes.

Se a utilização do endereço IP for alta (perto de 100%), considere estas soluções para evitar o esgotamento de endereços IP:

  • Adicione mais intervalos de endereços IPv4 do pod usando o CIDR de vários pods descontínuo. Com esse recurso, é possível adicionar mais endereços IPv4 aos pods sem precisar recriar o cluster ou configurar novas sub-redes.
  • Adicione mais sub-redes com outros intervalos de endereços IPv4 no cluster. Esse recurso permite que novos pools de nós usem endereços IP de sub-redes recém-adicionadas.
  • Crie um cluster com um valor menor para o número máximo de pods. Essa abordagem reserva menos endereços IP para cada nó, o que pode ajudar você a gerenciar o consumo geral de endereços IP no intervalo de rede do cluster. Para mais informações, consulte Configurar o máximo de pods por nó.
  • Se você não tiver intervalos de endereços IP ou espaço de endereço RFC 1918 suficientes, considere intervalos não RFC 1918 (incluindo o espaço de endereço da classe E).

Entender o cálculo de alocação de CIDR de pods do GKE

Uma fonte comum de confusão é que o GKE não aloca dinamicamente endereços IP de pods individuais de um pool central sob demanda. Em vez disso, quando um novo nó entra no cluster, o GKE separa um bloco CIDR contíguo do intervalo de pods secundário da sub-rede e o atribui exclusivamente a esse nó.

Para evitar colisões de reciclagem de IP durante implantações rápidas de pods, o GKE aloca um tamanho de bloco por nó igual ao menor bloco de potência de dois que contém pelo menos 2 × máximo de pods por nó:

Per-node Pod CIDR block size (addresses) = 2^(ceil(log2(2 * max_pods_per_node)))
  • Configuração padrão (--max-pods-per-node=110): requer pelo menos 2 × 110 = 220 endereços. A potência de dois mais próxima é 256 endereços, que atribui um bloco /24 (256 endereços IP) a cada nó.
  • Impacto na capacidade do nó do cluster: como cada nó consome um bloco /24 (256 endereços IP de pod), independentemente de quantos pods estão em execução nesse nó, o número máximo de nós com suporte de um intervalo de pod secundário depende diretamente da configuração de --max-pods-per-node:
Número máximo de pods por nó Bloco alocado por nó Máximo de nós por intervalo de pod /19 (8.192 endereços IP) Máximo de nós por intervalo de pods /16 (65.536 endereços IP)
110 (padrão) /24 (256 endereços IP) 32 nós 256 nós
64 /25 (128 endereços IP) 64 nós 512 nós
32 (padrão do Autopilot) /26 (64 endereços IP) 128 nós 1.024 nós
16 /27 (32 endereços IP) 256 nós 2.048 nós
8 /28 (16 endereços IP) 512 nós 4.096 nós

Resolver problemas específicos de rede

As seções a seguir fornecem orientações para resolver problemas relacionados a clusters nativos de VPC. Também é possível ver os insights de uso do endereço IP do GKE.

O recurso de rede padrão não está pronto

Sintomas

Você verá uma mensagem de erro semelhante a esta:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Causas possíveis

Há operações paralelas na mesma sub-rede. Por exemplo, outro cluster nativo de VPC está sendo criado ou um intervalo secundário está sendo adicionado ou excluído na sub-rede.

Resolução

Repita o comando.

Valor inválido para IPCidrRange.

Sintomas

Você verá uma mensagem de erro semelhante a esta:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Causas possíveis

Outro cluster nativo de VPC está sendo criado simultaneamente, e está tentando alocar os mesmos intervalos na mesma rede VPC.

O mesmo intervalo secundário está sendo adicionado à sub-rede na mesma rede VPC.

Resolução

Se esse erro reaparecer na criação do cluster, quando nenhum intervalo secundário foi especificado, tente executar novamente o comando de criação do cluster.

Não há espaço de endereços IP suficiente para o pod

Sintomas

O cluster está preso em um estado de provisionamento por um longo período de tempo

A criação de cluster retorna um erro do grupo gerenciado de instâncias (MIG, na sigla em inglês).

Quando você adiciona um ou mais nós a um cluster, o seguinte erro é exibido:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
Causas possíveis

Esgotamento de endereços IP para nós: o intervalo de endereços IP principal da sub-rede atribuída ao cluster fica sem endereços IP disponíveis. Isso geralmente acontece ao escalonar pools de nós ou criar clusters grandes.

Alta contagem inicial de nós em pools de nós com escala reduzida: o GKE reserva endereços IP para pods com base na capacidade inicial solicitada ao criar um pool de nós. Se você criar um pool de nós com um initial_node_count alto e reduzir escala vertical o número de nós, o GKE vai continuar reservando espaço de endereço IP com base no maior valor entre o initial_node_count do pool de nós ou o número atual de nós no pool. Essa situação pode levar a um estado em que o cluster informa o esgotamento do endereço IP, mesmo que o número atual de nós ativos seja baixo.

Esgotamento de endereços IP para pods: o intervalo CIDR do pod atribuído ao cluster está cheio. Isso ocorre quando o número de pods excede a capacidade do CIDR, especialmente com alta densidade de pods por nó ou implantações grandes.

Convenções específicas de nomenclatura de sub-rede: a forma como uma sub-rede é nomeada em uma mensagem de erro pode ajudar a descobrir se o problema está no intervalo de endereços IP para nós (em que os próprios nós recebem o intervalo de endereços IP) ou no intervalo de endereços IP para pods (em que os contêineres dentro dos pods recebem os endereços IP).

Esgotamento do intervalo secundário (Autopilot): nos clusters do Autopilot, os intervalos secundários atribuídos aos endereços IP para pods são esgotados devido ao escalonamento ou à alta densidade de pods.

Solução

Colete as seguintes informações sobre o cluster: nome, versão do plano de controle, modo de operação, nome da VPC associada, nome da sub-rede e CIDR. Além disso, observe todos os intervalos IPv4 padrão e adicionais para pods de cluster (incluindo nomes e CIDRs), se o roteamento de tráfego nativo da VPC está ativado e a configuração de pods máximos por nó nos níveis do cluster e do pool de nós (se aplicável). Observe os pools de nós afetados e os intervalos de endereços IPv4 específicos para pods e as configurações de pods máximos por nó, se forem diferentes das configurações de todo o cluster. Além disso, registre as configurações padrão e personalizadas (se houver) para os pods máximos por nó na configuração do pool de nós.

Confirmar problema de esgotamento de endereços IP

  • Network Intelligence Center: verifique se há altas taxas de alocação de endereços IP nos intervalos de endereços IP para pods no Network Intelligence Center do cluster do GKE.

    Se você observar uma alta taxa de alocação de endereços IP nos intervalos de pods no Network Intelligence Center, isso significa que o intervalo de endereços IP para pods está esgotado.

    Se os intervalos de endereços IP para pods mostrarem taxas de alocação normais, mas você ainda estiver enfrentando esgotamento de endereços IP, é provável que o intervalo de endereços IP para nós esteja esgotado.

  • Registros de auditoria: examine o campo resourceName nas entradas IP_SPACE_EXHAUSTED, comparando-o com os nomes de sub-redes ou nomes de intervalos de endereços IP secundários para pods.

  • Verifique se o intervalo de endereços IP esgotado é um intervalo de endereços IP para nós ou um intervalo de endereços IP para pods.

    Para verificar se o intervalo de endereços IP esgotado é um intervalo de endereços IP para nós ou intervalo de endereços IP para pods, verifique se o valor resourceName na parte ipSpaceExhausted de uma entrada de registro IP_SPACE_EXHAUSTED está relacionada ao nome da sub-rede ou ao nome do intervalo de endereços IPv4 secundário para pods usados no cluster do GKE afetado.

    Quando o valor de resourceName está no formato "[Subnet_name]", o intervalo de endereços IP para nós está esgotado. Quando o valor de resourceName está no formato "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", o intervalo de endereços IP para pods está esgotado.

Resolva o esgotamento de endereços IP para pods:

  • Redimensione o CIDR de pods existentes: aumente o tamanho do intervalo de endereços IP para pods existentes. É possível adicionar intervalos de IP do pod ao cluster usando CIDR de vários pods distintos.
  • Crie outras sub-redes: adicione ao cluster sub-redes com CIDRs de pods dedicados.

Reduza os pods por nó para liberar endereços IP:

Resolva o esgotamento de endereços IP para nós:

  • Revise o planejamento de endereços IP: verifique se o intervalo de endereços IP do nó está alinhado aos seus requisitos de escalonamento.
  • Crie um novo cluster (se necessário): se o intervalo de endereços IP para nós for muito restrito, crie um cluster de substituição com o dimensionamento adequado do intervalo de endereços IP. Consulte Intervalos de IPs para clusters nativos de VPC e Planejamento de intervalo de IPs.

Comandos de diagnóstico adicionais e playbooks de resolução não disruptiva

Para acelerar a solução de problemas e resolver o esgotamento de endereços IP, minimizando o tempo de inatividade do cluster, aplique os seguintes manuais de diagnóstico e operacionais:

1. Bissecção de linha de comando usando o Cloud Logging e o Recomendador

Para bissectar problemas de esgotamento de endereços IP na linha de comando, execute as seguintes tarefas:

  • Consulte o Cloud Logging para ver eventos explícitos de esgotamento de endereços IP: logquery resource.type="k8s_cluster" logName:"logs/container.googleapis.com" ("IP_SPACE_EXHAUSTED" OR "ran out of IPs" OR "wouldn't fit if a new node is added")
  • Consulte a API Recommender para receber insights automatizados do Network Analyzer (mais de 80% de utilização): sh gcloud recommender insights list \ --insight-type=google.networkanalyzer.container.ipAddressInsight \ --project=PROJECT_ID --location=GLOBAL
2. Expansão de sub-rede primária in-place em tempo real (para esgotamento de endereços IP primários de nós)

Ao contrário dos intervalos secundários, é possível expandir o intervalo de endereços IP do host principal de uma sub-rede em tempo real no Compute Engine sem recriar clusters ou interromper cargas de trabalho:

gcloud compute networks subnets expand-ip-range SUBNET_NAME \
    --region=REGION \
    --prefix-length=NEW_PREFIX_LENGTH

Por exemplo, expandir uma sub-rede principal de /24 para /22 aumenta a capacidade de endereços IP do host da VM principal de 252 para 1.020 nós de VM.

3. Manual de migração de pool de nós azul-verde (para esgotamento de endereços IP de pods)

Se um pool de nós atual estiver bloqueado em intervalos secundários pequenos ou na grande alocação de endereços IP da configuração padrão --max-pods-per-node=110, migre as cargas de trabalho para um novo pool de nós com CIDRs de tamanho adequado:

# Step 1: Add a new secondary IPv4 range to your subnet
gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --add-secondary-ranges=NEW_SECONDARY_RANGE_NAME=NEW_CIDR

# Step 2: Register the new Pod range with your GKE cluster
gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --additional-pod-ipv4-ranges=NEW_SECONDARY_RANGE_NAME

# Step 3: Launch a replacement node pool with right-sized --max-pods-per-node
gcloud container node-pools create pool-blue-v2 \
    --cluster=CLUSTER_NAME \
    --region=REGION \
    --max-pods-per-node=32 \
    --pod-ipv4-range=NEW_SECONDARY_RANGE_NAME \
    --enable-autoscaling --min-nodes=2 --max-nodes=60

# Step 4: Gracefully cordon and drain old nodes
kubectl cordon -l cloud.google.com/gke-nodepool=OLD_POOL_NAME
kubectl drain -l cloud.google.com/gke-nodepool=OLD_POOL_NAME --ignore-daemonsets --delete-emptydir-data --force --grace-period=300

# Step 5: Delete old node pool after workloads migrate
gcloud container node-pools delete OLD_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --region=REGION
4. Design de intervalo da classe E (240.0.0.0/4) com mascaramento de IP

Se a rede corporativa estiver com pouco espaço de endereço RFC 1918, aloque blocos IPv4 de classe E (240.0.0.0/4) para os intervalos de pods secundários (esses blocos fornecem mais de 268 milhões de endereços). Ative o agente de mascaramento de IP do GKE para que o tráfego de saída para bancos de dados locais ou outros endpoints de rede seja mascarado usando o endereço de host RFC 1918 principal do nó.

Depurar problemas de esgotamento de endereços IP com gcpdiag

gcpdiag é uma ferramenta de código aberto. Não é um produto do Google Cloud oficialmente compatível. Use a ferramenta gcpdiag para identificar e corrigir problemas no projeto do Google Cloud. Para mais informações, consulte o projeto gcpdiag no GitHub.

Para examinar as causas de esgotamento de endereços IP nos clusters do Autopilot e do GKE Standard, considere o seguinte:
  • Status do cluster: verifica o status do cluster se o esgotamento do endereço IP for relatado.
  • Network Analyzer: consulta os registros do Stackdriver em busca de registros do Network Analyzer para confirmar se há esgotamento de endereços IP de pods ou nós.
  • Tipo de cluster: verifica o tipo de cluster e fornece recomendações relevantes com base nele.

Console doGoogle Cloud

  1. Preencha e copie o comando a seguir. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. Abra o console do Google Cloud e ative o Cloud Shell.
    3. Abrir Console do Cloud
  3. Cole o comando copiado.
  4. Execute o comando gcpdiag, que faz o download da imagem Docker gcpdiag. e realiza verificações de diagnóstico. Se aplicável, siga as instruções de saída para corrigir verificações com falha.

Docker

Você pode executar gcpdiag usando um wrapper que inicia gcpdiag em um contêiner do Docker. Docker ou Podman precisa ser instalado.

  1. Copie e execute o seguinte comando na estação de trabalho local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Execute o comando gcpdiag. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

Veja os parâmetros disponíveis para este runbook.

Substitua:

  • PROJECT_ID: o ID do projeto que contém o recurso
  • CLUSTER_NAME: o nome do cluster do GKE de destino no seu projeto.
  • LOCATION: a zona ou região em que o cluster está localizado.
  • start_time: o horário em que o problema começou.
  • end_time: o horário em que o problema terminou. Defina o horário atual se o problema ainda estiver ocorrendo.

Flags úteis

Para conferir uma lista e descrição de todas as flags da ferramenta gcpdiag, consulte Instruções de uso do gcpdiag.

Confirmar se o SNAT padrão está desativado

Use o seguinte comando para verificar o status do SNAT padrão:

gcloud container clusters describe CLUSTER_NAME

Substitua CLUSTER_NAME pelo nome do cluster.

A saída será assim:

networkConfig:
  disableDefaultSnat: true
  network: ...

Não é possível usar --disable-default-snat sem --enable-ip-alias

Essa mensagem de erro e must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster significam que você precisa definir explicitamente a sinalização --disable-default-snat ao criar o cluster, já que está usando endereços IP públicos no cluster particular.

Se você vir mensagens de erro como cannot disable default sNAT ... , isso significa que o SNAT padrão não pode ser desativado no cluster. Para resolver esse problema, revise a configuração do cluster.

Como depurar o Cloud NAT com o SNAT padrão desativado

Se você tiver um cluster particular criado com a sinalização --disable-default-snat, tiver configurado o Cloud NAT para acesso à Internet e não estiver vendo o tráfego vinculado à Internet dos seus pods, verifique se o intervalo de pods está incluído na configuração do Cloud NAT.

Se houver um problema com a comunicação entre pods, examine as regras de iptables nos nós para verificar se os intervalos de pods não estão mascarados por regras de iptables.

Para mais informações, consulte a documentação de mascaramento de IP do GKE.

Se você não tiver configurado um agente de mascaramento de IP para o cluster, o GKE garantirá automaticamente que a comunicação entre pods não seja mascarada. No entanto, se um agente de mascaramento de IP estiver configurado, ele modificará as regras padrão de mascaramento de IP. Verifique se as regras extras estão configuradas no agente de mascaramento de IP para ignorar o mascaramento dos intervalos de pod.

A comunicação de rede do cluster de pilha dupla não está funcionando conforme o esperado

Causas possíveis
As regras de firewall criadas pelo cluster do GKE não incluem os endereços IPv6 alocados.
Resolução
Para validar a regra de firewall, siga estas etapas:

  1. Verifique o conteúdo da regra de firewall:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Substitua FIREWALL_RULE_NAME pelo nome da regra de firewall.

    Cada cluster de pilha dupla cria uma regra de firewall que permite que nós e pods se comuniquem uns com os outros. O conteúdo da regra de firewall é semelhante ao seguinte:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    O valor de sourceRanges precisa ser igual ao de subnetIpv6CidrBlock. O valor targetTags precisa ser igual às tags nos nós do GKE. Para corrigir esse problema, atualize a regra de firewall com as informações do bloco ipAllocationPolicy do cluster.

A seguir