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

Nesta seção há 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 de instâncias gerenciadas (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.

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.

Depurar problemas de esgotamento de endereços IP com gcpdiag

gcpdiag é uma ferramenta de código aberto. Não é um produto do Google Cloud com suporte oficial. 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 do esgotamento de endereços IP nos clusters do Autopilot e do GKE padrão, considere o seguinte:
  • Status do cluster:verifica o status do cluster se o esgotamento do endereço IP for informado.
  • 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.

Google Cloud console

  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 foi encerrado. Defina a hora 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