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

Nei cluster Google Kubernetes Engine (GKE) nativi di VPC, i nodi senza indirizzi IP esterni migliorano la sicurezza. Questi nodi utilizzano Cloud NAT per le connessioni a internet in uscita. La perdita di pacchetti può verificarsi se una VM nodo esaurisce le porte e gli indirizzi IP Cloud NAT allocati, spesso in condizioni di carico in uscita elevato, interrompendo il traffico in uscita.

Utilizza questo documento per scoprire come registrare e monitorare i pacchetti eliminati, esaminare la configurazione di Cloud NAT e implementare misure per ridurre la perdita di pacchetti futura.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma e per gli amministratori di rete che gestiscono i cluster GKE con nodi senza accesso a internet e si affidano a Cloud NAT per la connettività esterna. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

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 ignorati

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 ignorati, esegui una query su Osservatore metriche in Cloud Monitoring. I pacchetti vengono ignorati per uno dei tre motivi seguenti:

  • OUT_OF_RESOURCES
  • ENDPOINT_INDEPENDENT_CONFLICT
  • NAT_ALLOCATION_FAILED

Per identificare i pacchetti ignorati 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 che vengono ignorati per questi motivi, consulta Pacchetti ignorati per il motivo: risorse esaurite e Pacchetti ignorati per il motivo: conflitto indipendente dall'endpoint per suggerimenti sulla 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 È 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 principale 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 IP masquerading. 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 l'applicazione solo all'intervallo di indirizzi IP secondari 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 agli indirizzi IP esterni devono avere un indirizzo IP del pod di origine. In questa configurazione di Cloud NAT:

  • L'utilizzo di un agente di IP masquerading fa sì che i pacchetti perdano l'indirizzo IP del pod di origine quando vengono elaborati da Cloud NAT. Per mantenere 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 implementato 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.

Riduci la perdita di pacchetti

Dopo aver diagnosticato la causa della perdita di pacchetti, valuta la possibilità di utilizzare i seguenti consigli 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 tuple di indirizzi di origine e porte di origine NAT allocate.

    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