Risolvere i problemi di perdita di pacchetti Cloud NAT da un cluster

Questa pagina mostra come risolvere i problemi relativi alla perdita di pacchetti Cloud NAT da un cluster Google Kubernetes Engine (GKE) VPC nativo con nodi privati abilitati.

Le VM dei nodi nei cluster GKE nativi di VPC con nodi privati non hanno indirizzi IP esterni. Ciò significa che i client su internet non possono connettersi agli indirizzi IP dei nodi. Puoi utilizzare Cloud NAT per allocare gli indirizzi IP esterni e le porte che consentono ai cluster con nodi privati di stabilire connessioni pubbliche.

Se una VM nodo esaurisce l'allocazione di porte e indirizzi IP esterni da Cloud NAT, i pacchetti verranno eliminati. Per evitare questo problema, puoi ridurre la velocità dei pacchetti in uscita o aumentare l'allocazione di porte e indirizzi IP di origine Cloud NAT disponibili. Le seguenti sezioni descrivono come diagnosticare e risolvere i problemi di perdita di pacchetti da Cloud NAT nel contesto dei cluster GKE con nodi privati.

Diagnosticare la perdita di pacchetti

Le sezioni seguenti spiegano come registrare i pacchetti eliminati utilizzando Cloud Logging e diagnosticare la causa dell'eliminazione dei pacchetti utilizzando Cloud Monitoring.

Registra i pacchetti eliminati

Puoi registrare i pacchetti eliminati con la seguente query in Cloud Logging:

resource.type="nat_gateway"
resource.labels.region=REGION
resource.labels.gateway_name=GATEWAY_NAME
jsonPayload.allocation_status="DROPPED"

Sostituisci quanto segue:

  • REGION: il nome della regione in cui si trova il cluster.
  • GATEWAY_NAME: il nome del gateway Cloud NAT.

Questo comando restituisce un elenco di tutti i pacchetti eliminati da un gateway Cloud NAT, ma non identifica la causa.

Monitorare le cause della perdita di pacchetti

Per identificare le cause dei pacchetti eliminati, esegui una query nell'osservatore delle metriche in Cloud Monitoring. I pacchetti vengono eliminati per uno dei tre motivi seguenti:

  • OUT_OF_RESOURCES
  • ENDPOINT_INDEPENDENT_CONFLICT
  • NAT_ALLOCATION_FAILED

Per identificare i pacchetti eliminati a causa dei codici di errore OUT_OF_RESOURCES o ENDPOINT_ALLOCATION_FAILED, utilizza la seguente query:

fetch nat_gateway
  metric 'router.googleapis.com/nat/dropped_sent_packets_count'
  filter (resource.gateway_name == GATEWAY_NAME)
  align rate(1m)
  every 1m
  group_by [metric.reason],
    [value_dropped_sent_packets_count_aggregate:
       aggregate(value.dropped_sent_packets_count)]

Se identifichi pacchetti eliminati per questi motivi, consulta Pacchetti eliminati con il motivo: esaurimento delle risorse e Pacchetti eliminati con il motivo: conflitto di indipendenza degli endpoint per suggerimenti per la risoluzione dei problemi.

Per identificare i pacchetti eliminati a causa del codice di errore NAT_ALLOCATION_FAILED, utilizza la seguente query:

fetch nat_gateway
  metric 'router.googleapis.com/nat/nat_allocation_failed'
  group_by 1m,
    [value_nat_allocation_failed_count_true:
       count_true(value.nat_allocation_failed)]
  every 1m

Se identifichi pacchetti eliminati per questo motivo, consulta la sezione È necessario allocare più indirizzi IP.

Esamina la configurazione di Cloud NAT

Se le query precedenti restituiscono risultati vuoti e i pod GKE non riescono a comunicare con indirizzi IP esterni, utilizza la seguente tabella per risolvere i problemi di configurazione:

Configurazione Risoluzione dei problemi
Cloud NAT configurato per essere applicato solo all'intervallo di indirizzi IP primario della subnet. Quando Cloud NAT è configurato solo per l'intervallo di indirizzi IP primario della subnet, i pacchetti inviati dal cluster agli indirizzi IP esterni devono avere un indirizzo IP del nodo di origine. In questa configurazione di Cloud NAT:
  • I pod possono inviare pacchetti a indirizzi IP esterni se queste destinazioni di indirizzi IP esterni sono soggette a mascheramento IP. Quando esegui il deployment di ip-masq-agent, verifica che l'elenco nonMasqueradeCIDRs non contenga l'indirizzo IP e la porta di destinazione. I pacchetti inviati a queste destinazioni vengono prima convertiti in indirizzi IP del nodo di origine prima di essere elaborati da Cloud NAT.
  • Per consentire ai pod di connettersi a tutti gli indirizzi IP esterni con questa configurazione Cloud NAT, assicurati che ip-masq-agent sia implementato e che l'elenco nonMasqueradeCIDRs contenga solo gli intervalli di indirizzi IP di nodi e pod del cluster. I pacchetti inviati a destinazioni esterne al cluster vengono prima convertiti in indirizzi IP del nodo di origine prima di essere elaborati da Cloud NAT.
  • Per impedire ai pod di inviare pacchetti ad alcuni indirizzi IP esterni, devi bloccare esplicitamente questi indirizzi in modo che non vengano mascherati. Quando viene eseguito il deployment di ip-masq-agent, aggiungi gli indirizzi IP esterni che vuoi bloccare all'elenco nonMasqueradeCIDRs. I pacchetti inviati a queste destinazioni lasciano il nodo con le origini dell'indirizzo IP del pod originale. Gli indirizzi IP dei pod provengono da un intervallo di indirizzi IP secondario della subnet del cluster. In questa configurazione, Cloud NAT non opererà su questo intervallo secondario.
Cloud NAT configurato per essere applicato solo all'intervallo di indirizzi IP secondario della subnet utilizzato per gli IP dei pod.

Quando Cloud NAT è configurato solo per l'intervallo di indirizzi IP secondari della subnet utilizzato dagli IP dei pod del cluster, i pacchetti inviati dal cluster a indirizzi IP esterni devono avere un indirizzo IP del pod di origine. In questa configurazione di Cloud NAT:

  • L'utilizzo di un agente di mascheramento IP fa sì che i pacchetti perdano l'indirizzo IP del pod di origine quando vengono elaborati da Cloud NAT. Per conservare l'indirizzo IP del pod di origine, specifica gli intervalli di indirizzi IP di destinazione in un elenco nonMasqueradeCIDRs. Con ip-masq-agent di cui è stato eseguito il deployment, tutti i pacchetti inviati alle destinazioni nell'elenco nonMasqueradeCIDRs mantengono i propri indirizzi IP dei pod di origine prima di essere elaborati da Cloud NAT.
  • Per consentire ai pod di connettersi a tutti gli indirizzi IP esterni con questa configurazione Cloud NAT, assicurati che ip-masq-agent sia stato eseguito il deployment e che l'elenco nonMasqueradeCIDRs sia il più grande possibile (0.0.0.0/0 specifica tutte le destinazioni di indirizzi IP). I pacchetti inviati a tutte le destinazioni conservano gli indirizzi IP dei pod di origine prima di essere elaborati da Cloud NAT.

Ridurre la perdita di pacchetti

Dopo aver diagnosticato la causa della perdita di pacchetti, valuta la possibilità di utilizzare i seguenti suggerimenti per ridurre la probabilità che il problema si ripresenti in futuro:

  • Configura il gateway Cloud NAT in modo che utilizzi l'allocazione dinamica delle porte e aumenta il numero massimo di porte per VM.

  • Se utilizzi l'allocazione statica delle porte, aumenta il numero minimo di porte per VM.

  • Riduci la velocità dei pacchetti in uscita della tua applicazione. Quando un'applicazione effettua più connessioni in uscita allo stesso indirizzo IP e alla stessa porta di destinazione, può consumare rapidamente tutte le connessioni che Cloud NAT può stabilire con quella destinazione utilizzando il numero di indirizzi di origine NAT e di tuple di porte di origine allocati.

    Per informazioni dettagliate su come Cloud NAT utilizza gli indirizzi di origine NAT e le porte di origine per stabilire connessioni, inclusi i limiti al numero di connessioni simultanee a una destinazione, consulta Porte e connessioni.

    Per ridurre la frequenza delle connessioni in uscita dall'applicazione, riutilizza le connessioni aperte. I metodi comuni di riutilizzo delle connessioni includono il pooling delle connessioni, il multiplexing delle connessioni utilizzando protocolli come HTTP/2 o la creazione di connessioni persistenti riutilizzate per più richieste. Per saperne di più, vedi Porte e connessioni.

Passaggi successivi