Resolva problemas do Cloud NAT

Este guia ajuda a diagnosticar o motivo pelo qual as suas cargas de trabalho (pods ou VMs) não conseguem aceder a redes externas através do Cloud NAT. Como programador, interage principalmente com o recurso CloudNatGateway. O estado deste recurso é a sua principal fonte de informações fidedignas para a depuração.

Antes de começar

Para resolver problemas de uma configuração do Cloud NAT, tem de ter o seguinte:

  • As funções de identidade e acesso necessárias. Peça ao administrador de IAM do projeto para lhe conceder uma ou ambas as seguintes funções:
    • Visualizador do NAT na nuvem (cloud-nat-viewer): esta função oferece acesso só de leitura aos recursos do NAT na nuvem. Esta função ajuda a começar a diagnosticar o problema.
    • Programador do NAT na nuvem (cloud-nat-developer): esta função concede as autorizações necessárias aos operadores de aplicações para criar, ler, atualizar e eliminar (CRUD) objetos do NAT na nuvem nos respetivos projetos atribuídos. Esta função permite-lhe fazer muitas das correções descritas nesta página.
    • Podem ser necessários papéis adicionais para algumas medidas de diagnóstico e correções específicas.

Diagnósticos iniciais

Antes de analisar os códigos de erro, certifique-se de que os recursos básicos estão presentes e acessíveis.

Comando:

kubectl get cloudnatgateway GATEWAY_NAME -n PROJECT_NAMESPACE -o yaml

Substitua o seguinte:

  • GATEWAY_NAME: o nome do recurso CloudNatGateway.
  • PROJECT_NAMESPACE: o espaço de nomes do seu projeto.

Verifique as condições de estado: um gateway em bom estado tem de ter todas as seguintes condições definidas como True:

  • Ready: estado de saúde global.
  • SubnetsReady: a configuração do conjunto de IPs é válida.
  • PerimeterConfigurationReady: a infraestrutura de rede a montante está configurada.
  • EgressRoutesReady: as políticas de encaminhamento dos seus pods estão ativas.

Se algum destes campos for False, verifique os campos reason e message na saída de estado e consulte as tabelas nas secções seguintes.

Referência e correção do código de erro

Os códigos de erro devolvidos por kubectl get cloudnatgateway enquadram-se em três categorias principais.

Erros de sub-rede (SubnetsReady é False)

Esta condição indica problemas com o conjunto de endereços IP atribuído ao gateway.

Código de erro Significado Passos de remediação
CloudNATSelectorFieldOverlapsCode Conflito de configuração. O workloadSelector desta entrada corresponde às mesmas cargas de trabalho que outra entrada no seu projeto. Não é possível encaminhar o tráfego de forma determinística.
  1. Apresente todas as gateways do Cloud NAT no seu projeto: kubectl get cloudnatgateway
  2. Compare o workloadSelector desta entrada com outras.
  3. Modifique as etiquetas para que nenhum Pod/VM seja selecionado por mais do que um gateway.
CloudNATSubnetRefsFieldInvalidCode

Sub-rede inválida. A sub-rede especificada em subnetRefs não é utilizável. Motivos comuns:

  • A sub-rede não existe.
  • A sub-rede não está no estado Ready.
  • A sub-rede não é do tipo Leaf.
  1. Verifique se a sub-rede existe: kubectl get subnet <SUBNET_NAME>
  2. Verifique se o estado da sub-rede é Ready.
  3. Certifique-se de que a sub-rede type é Leaf (o Cloud NAT não pode usar sub-redes de raiz ou de loopback).
CloudNATSubnetAlreadyInUseCode Conflito de sub-rede. A sub-rede que pediu já é "detida" por outro gateway NAT da nuvem. Uma sub-rede só pode ser anexada a um gateway de cada vez.
  1. Escolha uma sub-rede diferente para este gateway.
  2. Em alternativa, remova primeiro a sub-rede do outro gateway.
UNETAPIServerErrorCode Erro do sistema. O controlador não consegue comunicar com o servidor da API para validar as sub-redes. Ação: este é provavelmente um problema temporário da plataforma. Se o problema persistir, contacte o administrador da plataforma.

Erros de configuração do perímetro (PerimeterConfigurationReady é False)

Esta condição reflete o estado dos gateways de perímetro.

Código de erro Significado Passos de remediação
NET-E0305 Conflito de configuração. (O mesmo que acima). Os seletores sobrepostos impedem o sistema de calcular o grupo de encaminhamento correto.
  1. Apresente todas as gateways do Cloud NAT no seu projeto: kubectl get cloudnatgateway
  2. Compare o workloadSelector desta entrada com outras.
  3. Modifique as etiquetas para que nenhum Pod/VM seja selecionado por mais do que um gateway.
NET-E0301 Esgotamento de recursos / falha do nó. O sistema criou a configuração, mas não conseguiu atribuir os seus IPs de saída a um nó físico em bom estado. Normalmente, isto significa que a sub-rede está sem IPs ou que os nós de gateway estão inativos.
  1. Verifique a utilização da [sub-rede](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/subnets-overview). Está cheio?
  2. Se a sub-rede tiver IPs livres e estiver Ready, isto indica uma falha de infraestrutura do lado da plataforma (por exemplo, não existem nós de gateway saudáveis disponíveis). Ação: contacte o administrador da plataforma.
NET-E0001 Erro do sistema. Falha na comunicação do controlador. Ação: contacte o administrador da plataforma.

Erros de rota de saída (EgressRoutesReady é False)

Esta condição reflete o estado das políticas de encaminhamento no cluster.

Código de erro Significado Passos de remediação
NET-E0305 Conflito de configuração. (O mesmo que acima).
  1. Apresente todas as gateways do Cloud NAT no seu projeto: kubectl get cloudnatgateway
  2. Compare o workloadSelector desta entrada com outras.
  3. Modifique as etiquetas para que nenhum Pod/VM seja selecionado por mais do que um gateway.
NET-E0304 Falha de programação. O sistema não conseguiu programar as regras de encaminhamento (BPF) para os seus IPs de gateway específicos.

Ação: trata-se de um erro de programação interno ou de uma inconsistência de estado.

  1. Experimente fazer uma atualização trivial ao gateway (por exemplo, editar uma etiqueta) para acionar uma conciliação.
  2. Se persistir, contacte o administrador da plataforma.

Outros problemas comuns

Se o estado do gateway for Ready: True, mas o tráfego continuar a falhar, verifique estas configurações incorretas comuns:

Autorização ao nível do projeto em falta

O seu projeto tem de estar explicitamente autorizado a enviar tráfego.

  • Verifique: o recurso Project tem a etiqueta networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true"?
  • Correção: peça ao administrador do projeto para aplicar esta etiqueta.

Anotação de VM em falta (apenas para máquinas virtuais)

As VMs ignoram o caminho de saída do pod padrão e precisam de instruções explícitas para usar o Cloud NAT.

  • Verifique: o objeto VirtualMachineExternalAccess (VMEA) da sua VM tem a anotação egress.networking.gke.io/use-cloud-nat: "true"?
  • Corrigir: adicione a anotação ao objeto VMEA.

Saída do nó do cluster padrão

Se estiver a executar um cluster padrão, os próprios nós precisam de autorização para sair.

  • Verifique: o objeto Cluster tem a etiqueta cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true"?
  • Correção: peça ao administrador da plataforma para etiquetar o objeto Cluster.

Colisão entre o NAT de saída predefinido e o Cloud NAT

Ocorre um erro de configuração comum quando uma carga de trabalho está configurada para usar o mecanismo NAT de saída predefinido antigo e, simultaneamente, é selecionada por um gateway NAT da nuvem. Esta combinação resulta numa colisão em que o plano de dados recebe instruções de encaminhamento em conflito, o que leva à perda de pacotes ou a um comportamento de encaminhamento não determinístico.

Diagnostique colisões de agrupamentos

Para os pods, o NAT de saída predefinido é normalmente ativado adicionando uma etiqueta específica. Um Pod não pode ter esta etiqueta e ser segmentado por um gateway NAT da nuvem.

  1. Identifique o Target Pod: obtenha as etiquetas do Pod que está a ter problemas de conetividade.

    kubectl get pod <POD_NAME> -n <NAMESPACE> --show-labels

  2. Verifique se existem etiquetas em conflito:

    • Seleção de NAT da nuvem: as etiquetas do pod correspondem ao workloadSelector de qualquer CloudNatGateway no espaço de nomes?
    • Etiqueta de saída predefinida: o pod tem a etiqueta egress.networking.gke.io/enabled: "true"?

    Condição: se AMBAS forem verdadeiras, tem uma colisão.

  3. Resolução: remova a etiqueta de saída predefinida antiga do pod (ou da respetiva implementação/conjunto com estado principal) para permitir que o Cloud NAT assuma o controlo exclusivo.

Diagnostique colisões de VMs

Para máquinas virtuais, o mecanismo é diferente. As VMs com objetos VirtualMachineExternalAccess (VMEA) são frequentemente configuradas para acesso predefinido. Para usar o Cloud NAT, têm de ativar explicitamente esta opção adicionando uma anotação para desativar o caminho predefinido e ativar o caminho do Cloud NAT.

  1. Identifique o VMEA: encontre o objeto VirtualMachineExternalAccess associado à VM.

    kubectl get vmea -n <NAMESPACE>

  2. Verifique se existem anotações em falta:

    • Seleção do Cloud NAT: as etiquetas da VM correspondem a um CloudNatGateway?
    • Anotação de aceitação: verifique o VMEA da anotação egress.networking.gke.io/use-cloud-nat: "true".

    Condição: se a VM corresponder a um gateway, mas NÃO TIVER esta anotação, o tráfego vai entrar em conflito com o sistema de saída predefinido.

  3. Resolução: adicione a anotação ao objeto VMEA.

    kubectl annotate vmea <VMEA_NAME> -n <NAMESPACE> egress.networking.gke.io/use-cloud-nat="true"