Resolva problemas de gestão de endereços IP em clusters de VPC

Esta página ajuda a resolver problemas com a gestão de endereços IP em clusters de VPC no Google Kubernetes Engine (GKE).

Esta página orienta os administradores e os operadores da plataforma na deteção e resolução de problemas, como o esgotamento de endereços IP para nós e pods, a resolução de problemas de erros de configuração de rede que bloqueiam as operações do cluster (como conflitos de intervalos), a gestão de intervalos CIDR de endereços IP e a configuração correta de funcionalidades como o SNAT predefinido, o Cloud NAT e a rede de pilha dupla.

Esta página também ajuda os programadores de aplicações a compreenderem como as limitações de rede subjacentes, como o espaço de IP esgotado, podem afetar as respetivas cargas de trabalho, o que leva a problemas como a falha na programação de pods. Embora os programadores possam não configurar diretamente as VPCs, a compreensão destes problemas comuns ajuda-os a colaborar melhor com os administradores e os operadores da plataforma para resoluções mais rápidas. Para mais informações sobre as funções comuns e exemplos de tarefas que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Diagnostique o esgotamento de endereços IP

A falta de endereços IP no cluster pode impedir o dimensionamento dos nós e interromper as cargas de trabalho. Esta secção explica como usar a monitorização da utilização de endereços IP no GKE para detetar e resolver potenciais problemas de esgotamento.

O GKE calcula a utilização de endereços IP com base em dados das estatísticas do Analisador de rede e de outras origens de dados do GKE. Esta monitorização está disponível para todos os clusters nativos da VPC.

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

  1. Na Google Cloud consola, aceda à página Clusters do Kubernetes.

    Aceda aos clusters do Kubernetes

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

  3. Navegue para a página Utilização de IP através de um dos seguintes métodos:

    • Selecione o separador Observabilidade e, de seguida, no menu de navegação de observabilidade, clique em Utilização de IPs.

    • Na secção Redes, localize a linha Intervalo IPv4 do cluster de pods (predefinição) e clique em Ver utilização de IP.

  4. Reveja a coluna Estado da atribuição de IP. Esta coluna mostra a percentagem de endereços IP atribuídos no intervalo de endereços IP do seu 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. Este comportamento significa que a percentagem reflete o intervalo de pods completo de um nó e não apenas os endereços IP em utilização. Se os clusters partilharem os mesmos intervalos de endereços IP, a percentagem de utilização mostra o total combinado.

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

Se a utilização do seu endereço IP for elevada (a aproximar-se dos 100%), considere estas soluções para evitar o esgotamento de endereços IP:

  • Adicione mais intervalos de endereços IPv4 de pods usando o CIDR multi-pod não contíguo. Esta funcionalidade permite-lhe adicionar mais endereços IPv4 para os seus pods sem ter de recriar o cluster nem configurar novas sub-redes.
  • Adicione mais sub-redes com intervalos de endereços IPv4 adicionais no cluster. Esta funcionalidade permite que os novos conjuntos de nós usem endereços IP de sub-redes adicionadas recentemente.
  • Crie um novo cluster com um valor inferior para o número máximo de pods. Esta abordagem reserva menos endereços IP para cada nó, o que pode ajudar a gerir o consumo geral de endereços IP no intervalo de rede do cluster. Para mais informações, consulte o artigo Configure o número máximo de pods por nó.
  • Se não tiver intervalos de endereços IP ou espaço de endereços RFC 1918 suficientes, considere intervalos não RFC 1918 (incluindo o espaço de endereços de classe E).

Resolva problemas de rede específicos

As secções seguintes fornecem orientações para resolver problemas relacionados com clusters nativos da VPC. Também pode ver estatísticas de utilização de endereços IP do GKE.

O recurso de rede predefinido não está pronto

Sintomas

Recebe uma mensagem de erro semelhante à seguinte:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Potenciais causas

Existem operações paralelas na mesma sub-rede. Por exemplo, está a ser criado outro cluster nativo da VPC ou está a ser adicionado ou eliminado um intervalo secundário na sub-rede.

Resolução

Tente novamente o comando.

Valor inválido para IPCidrRange

Sintomas

Recebe uma mensagem de erro semelhante à seguinte:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Potenciais causas

Está a ser criado outro cluster nativo da VPC ao mesmo tempo e está a tentar atribuir os mesmos intervalos na mesma rede da VPC.

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

Resolução

Se este erro for devolvido na criação do cluster quando não foram especificadas intervalos secundários, tente novamente o comando de criação do cluster.

Não existe espaço de endereço IP livre suficiente para os pods

Sintomas

O cluster está bloqueado num estado de aprovisionamento durante um longo período.

A criação do cluster devolve um erro do grupo de instâncias geridas (MIG).

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

[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]'.
Potenciais causas

Esgotamento do endereço IP do nó: o intervalo de endereços IP principal da sub-rede atribuída ao seu cluster fica sem endereços IP disponíveis. Normalmente, isto acontece quando dimensiona node pools ou cria clusters grandes.

Esgotamento do endereço IP do pod: o intervalo CIDR do pod atribuído ao seu cluster está cheio. Isto ocorre quando o número de pods excede a capacidade do CIDR do pod, especialmente com uma elevada densidade de pods por nó ou implementações grandes.

Convenções de nomenclatura de sub-redes específicas: a forma como uma sub-rede é denominada numa mensagem de erro pode ajudar a determinar se o problema está no intervalo de endereços IP dos nós (onde os próprios nós obtêm o respetivo endereço IP) ou no intervalo de endereços IP dos pods (onde os contentores nos pods obtêm os respetivos endereços IP).

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

Solução

Reúna as seguintes informações sobre o seu cluster: nome, versão do plano de controlo, modo de funcionamento, nome da VPC associada e nome e CIDR da sub-rede. Além disso, tenha em atenção os intervalos IPv4 do agrupamento de pods predefinidos e adicionais (incluindo nomes e CIDRs), se o encaminhamento de tráfego nativo da VPC está ativado e a definição de pods máximos por nó ao nível do cluster e do conjunto de nós (se aplicável). Tome nota de todos os conjuntos de nós afetados e dos respetivos intervalos de endereços IP de pods IPv4 específicos, bem como das configurações de pods máximos por nó, se forem diferentes das definições ao nível do cluster. Além disso, registe as configurações predefinidas e personalizadas (se existirem) para o número máximo de agrupamentos por nó na configuração do conjunto de nós.

Confirme o problema de esgotamento de endereços IP

  • Network Intelligence Center: verifique se existem taxas de atribuição de endereços IP elevadas nos intervalos de endereços IP dos pods no Network Intelligence Center para o seu cluster do GKE.

    Se observar uma taxa de atribuição de endereços IP elevada nos intervalos de pods no Network Intelligence Center, significa que o intervalo de endereços IP de pods está esgotado.

    Se os intervalos de endereços IP dos pods mostrarem taxas de atribuição normais, mas continuar a ter problemas de esgotamento de endereços IP, é provável que o intervalo de endereços IP dos nós esteja esgotado.

  • Registos de auditoria: examine o campo resourceName nas entradas, comparando-o com os nomes das sub-redes ou os nomes do intervalo de endereços IP dos pods secundários.IP_SPACE_EXHAUSTED

  • Verifique se o intervalo de endereços IP esgotado é o intervalo de endereços IP do nó ou o intervalo de endereços IP do pod.

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

    Se o valor de resourceName estiver no formato "[Subnet_name]", significa que o intervalo de endereços IP do nó está esgotado. Se o valor de resourceName estiver no formato "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", significa que o intervalo de endereços IP de pods está esgotado.

Resolva o esgotamento do endereço IP do pod:

  • Redimensionar CIDR de pods existente: aumente o tamanho do intervalo de endereços IP de pods atual. Pode adicionar intervalos de IPs de pods ao cluster através do CIDR de vários pods não contíguos.
  • Crie sub-redes adicionais: adicione sub-redes com CIDRs de pods dedicados ao cluster.

Reduza o número de pods por nó para libertar endereços IP:

Esgotamento do endereço IP do nó de endereço:

  • Reveja o planeamento de endereços IP: certifique-se de que o intervalo de endereços IP dos nós está alinhado com os seus requisitos de escalabilidade.
  • Crie um novo cluster (se necessário): se o intervalo de endereços IP dos nós estiver muito restrito, crie um cluster de substituição com o dimensionamento do intervalo de endereços IP adequado. Consulte os intervalos de IP para clusters nativos da VPC e o planeamento de intervalos de IP.

Depure problemas de esgotamento de endereços IP com o gcpdiag

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

Para examinar as causas do esgotamento de endereços IP em clusters do Autopilot e do GKE Standard, considere o seguinte:
  • Estado do cluster: verifica o estado do cluster se for comunicado o esgotamento de endereços IP.
  • Analisador de rede: consulta os registos do Stackdriver para ver se existem registos do analisador de rede que confirmem se existe esgotamento do endereço IP do nó ou do pod.
  • Tipo de cluster: verifica o tipo de cluster e fornece recomendações relevantes com base no tipo de cluster.

Google Cloud consola

  1. Conclua e, em seguida, copie o seguinte comando. 
    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 a Google Cloud consola e ative o Cloud Shell.
    3. Abra a Cloud Console
  3. Cole o comando copiado.
  4. Execute o comando gcpdiag, que transfere a imagem do Docker gcpdiag e, em seguida, faz verificações de diagnóstico. Se aplicável, siga as instruções de saída para corrigir as verificações com falhas.

Docker

Pode executar o gcpdiag usando um wrapper que inicia o gcpdiag num contentor do Docker. O Docker ou o Podman têm de estar instalados.

  1. Copie e execute o seguinte comando na sua 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 manual de procedimentos.

Substitua o seguinte:

  • 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 a região onde o cluster está localizado.
  • start_time: a hora em que o problema começou.
  • end_time: a hora em que o problema terminou. Defina a hora atual se o problema persistir.

Sinalizações úteis:

Para ver uma lista e uma descrição de todas as flags da ferramenta gcpdiag, consulte as gcpdiag instruções de utilização.

Confirme se o SNAT predefinido está desativado

Use o seguinte comando para verificar o estado do SNAT predefinido:

gcloud container clusters describe CLUSTER_NAME

Substitua CLUSTER_NAME pelo nome do seu cluster.

O resultado é semelhante ao seguinte:

networkConfig:
  disableDefaultSnat: true
  network: ...

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

Esta mensagem de erro e must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster significam que deve definir explicitamente a flag --disable-default-snat quando criar o cluster, uma vez que está a usar endereços IP públicos no seu cluster privado.

Se vir mensagens de erro como cannot disable default sNAT ... , significa que não é possível desativar o SNAT predefinido no seu cluster. Para resolver este problema, reveja a configuração do cluster.

Depurar o Cloud NAT com o SNAT predefinido desativado

Se tiver um cluster privado criado com a flag --disable-default-snat e tiver configurado o Cloud NAT para acesso à Internet, e não vir tráfego associado à Internet a partir dos seus pods, certifique-se de que o intervalo de pods está incluído na configuração do Cloud NAT.

Se existir um problema com a comunicação de pod para pod, 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 sobre a ocultação de IP do GKE.

Se não tiver configurado um agente de ocultação de IP para o cluster, o GKE garante automaticamente que a comunicação de pod para pod não é ocultada. No entanto, se estiver configurado um agente de ocultação de IP, este substitui as regras de ocultação de IP predefinidas. Verifique se existem regras adicionais configuradas no agente de ocultação de IP para ignorar a ocultação dos intervalos de pods.

A comunicação de rede do cluster de pilha dupla não está a funcionar como esperado

Potenciais causas
As regras de firewall criadas pelo cluster do GKE não incluem os endereços IPv6 atribuídos.
Resolução
Pode validar a regra da firewall através destes passos:

  1. Valide 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 os nós e os pods comuniquem entre si. 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 tem de ser igual ao de subnetIpv6CidrBlock. O valor targetTags tem de ser igual às etiquetas nos nós do GKE. Para corrigir este problema, atualize a regra da firewall com as informações de bloqueio do cluster ipAllocationPolicy.

O que se segue?