Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Configurazione della connettività del pod GKE all'endpoint esterno

Autopilot Standard

Questo documento spiega come configurare la connettività dai pod in GKE agli endpoint esterni, incluse le risorse nelle reti on-premise e i servizi internet pubblici. Per controllare l'indirizzo IP di origine del traffico dei pod GKE, puoi utilizzare sia ip-masq-agent (conversione a livello di nodo) sia Cloud NAT (uscita a livello di VPC).

Panoramica

Quando un pod in un cluster GKE nativo del VPC invia un pacchetto a una destinazione esterna al cluster, l'indirizzo IP di origine del pacchetto cambia a seconda della configurazione dell'agente di mascheramento IP a livello di nodo (ip-masq-agent) e di Cloud NAT.

Conversione a livello di nodo (ip-masq-agent): converte l'indirizzo IP di origine del pacchetto dall'indirizzo IP del pod (intervallo di subnet secondario) all'indirizzo IP del nodo interno (intervallo di subnet primario) in base a un elenco nonMasqueradeCIDRs configurato.
Gateway a livello di VPC (Cloud NAT): converte gli indirizzi IP interni del VPC (indirizzi IP dei nodi o indirizzi IP dei pod) in indirizzi IP pubblici statici per consentire l'accesso a internet in uscita.

A seconda che una destinazione sia mascherata dal nodo, il pacchetto lascia il nodo con l'indirizzo IP del nodo o con l'indirizzo IP del pod. Questo indirizzo IP di origine determina la configurazione dei router Cloud o dei router on-premise.

Come funzionano insieme IP masquerading e Cloud NAT

Per il traffico con accesso a internet, i pacchetti di un pod attraversano sia lo stack di rete del nodo sia il gateway Cloud NAT.

Scenario A: mascheramento dell'indirizzo IP del nodo (consigliato per il traffico in uscita da internet)

Se l'indirizzo IP di destinazione non corrisponde a nessun intervallo nell'elenco nonMasqueradeCIDRs:

ip-masq-agent esegue SNAT (Source NAT) sul nodo GKE. L'indirizzo IP di origine viene riscritto dall'indirizzo IP del pod all'indirizzo IP del nodo.
Il pacchetto entra nella rete VPC con l'indirizzo IP del nodo come origine.
Il gateway Cloud NAT intercetta il pacchetto.
Cloud NAT converte l'indirizzo IP del nodo in un indirizzo IP pubblico e lo instrada a internet.

Scenario B: conservazione dell'indirizzo IP del pod (nessun mascheramento)

Se l'indirizzo IP di destinazione corrisponde a un intervallo nell'elenco nonMasqueradeCIDRs (o se SNAT predefinito è disabilitato):

ip-masq-agent lascia il pacchetto invariato. L'indirizzo IP di origine rimane l'indirizzo IP del pod.
Il pacchetto entra nella rete VPC con l'indirizzo IP del pod come origine.
Il gateway Cloud NAT intercetta il pacchetto.
Cloud NAT converte l'indirizzo IP del pod in un indirizzo IP pubblico solo se Cloud NAT è configurato in modo esplicito per convertire l'intervallo di indirizzi IP secondari della subnet utilizzato per i pod GKE.

Controllo del mascheramento IP

Utilizza questo controllo per verificare se un indirizzo IP di destinazione verrà mascherato in base alla configurazione di ip-masq-agent.

Esempio di flusso di traffico

Per comprendere il percorso di conversione, considera la seguente configurazione di esempio:

Intervallo di indirizzi IP del pod: 10.4.0.0/14 (indirizzo IP del pod: 10.4.0.5)
Intervallo di indirizzi IP del nodo: 10.128.0.0/20 (indirizzo IP del nodo: 10.128.0.10)
Indirizzo IP di destinazione: 8.8.8.8 (server DNS pubblico, non presente nell'elenco nonMasqueradeCIDRs)

Quando il pod invia un pacchetto, si verifica quanto segue:

Il pacchetto inizia dal pod: il pacchetto ha origine dall'interfaccia di rete del pod (indirizzo IP: 10.4.0.5) con un indirizzo IP di destinazione 8.8.8.8.
Mascheramento a livello di nodo: poiché l'indirizzo IP di destinazione 8.8.8.8 non è presente nell'elenco nonMasqueradeCIDRs, ip-masq-agent sul nodo host intercetta il pacchetto quando esce ed esegue SNAT. L'indirizzo IP di origine viene riscritto dall'indirizzo IP del pod 10.4.0.5 all'indirizzo IP del nodo host, ovvero 10.128.0.10.
Traffico in uscita dal VPC: il pacchetto raggiunge la rete VPC utilizzando l'indirizzo IP del nodo host 10.128.0.10 come indirizzo IP di origine.
Gateway Cloud NAT: poiché la destinazione è la rete internet pubblica, Cloud NAT elabora il pacchetto, converte l'indirizzo IP di origine da 10.128.0.10 a un indirizzo IP NAT pubblico (ad esempio, 203.0.113.1) e lo inoltra a internet.
Gestione delle risposte: la risposta torna all'indirizzo IP Cloud NAT pubblico, che Cloud NAT converte nuovamente all'indirizzo IP del nodo host 10.128.0.10. Il nodo converte quindi l'indirizzo IP del nodo host all'indirizzo IP del pod, ovvero 10.4.0.5, e lo consegna al container del pod.

Flusso di traffico con Cloud Service Mesh (CSM)

Se i tuoi carichi di lavoro utilizzano Cloud Service Mesh, il routing del traffico si comporta nel seguente modo:

Reindirizzamento del proxy sidecar o CNI senza sidecar: i pacchetti in uscita dal container dell'applicazione vengono intercettati dalla mesh (utilizzando un proxy sidecar come Envoy o tramite reindirizzamento basato su ebpf o CNI) prima di raggiungere lo spazio dei nomi di rete del nodo.
Applicazione delle policy: la mesh determina se la connessione è consentita in base alle policy di autorizzazione e in uscita.
Routing in uscita:
- Se il traffico viene indirizzato utilizzando un gateway in uscita di Cloud Service Mesh, l'indirizzo IP di origine del pacchetto che lascia il nodo corrisponde all'indirizzo IP del nodo o del pod del gateway in uscita, anziché al pod di origine.
- Se il traffico viene instradato direttamente all'endpoint esterno, il pacchetto esce dal proxy e viene instradato tramite lo stack di rete del nodo host standard. In questo caso, le policy ip-masq-agent e le configurazioni di Cloud NAT descritte in precedenza in questo documento si applicano comunque al traffico in uscita.
Per ulteriori informazioni sulla configurazione del routing, dei gateway e sulla gestione del traffico esterno in Cloud Service Mesh, consulta la documentazione di Cloud Service Mesh.

Risoluzione dei problemi e isolamento dei problemi di connettività

Se un pod non riesce a connettersi a un endpoint esterno e utilizzi una mesh di servizi, devi isolare se il problema riguarda la configurazione della mesh di servizi o il routing GKE sottostante. Per isolare il problema, utilizza il seguente metodo:

Ignora la mesh di servizi: esegui il deployment di un pod client temporaneo in uno spazio dei nomi in cui l'inserimento del sidecar è disabilitato oppure utilizza l'annotazione sidecar.istio.io/inject: "false" nella specifica del pod per impedire l'inserimento per il carico di lavoro di test.
Testa la connettività: tenta di connetterti alla destinazione esterna (ad esempio utilizzando curl, ping o nc) dal pod non mesh.
Analizza i risultati:
- Se la connessione ha esito positivo: il routing di rete GKE sottostante, le regole ip-masq-agent e il gateway Cloud NAT sono configurati correttamente. Il blocco della connettività è causato da policy di Cloud Service Mesh, regole in uscita mancanti o regole mTLS. Per ulteriori informazioni sulla risoluzione dei problemi, consulta Risoluzione dei problemi relativi ai deployment che utilizzano Envoy nella documentazione di Cloud Service Mesh.
- Se la connessione non riesce: il problema riguarda l'infrastruttura di rete sottostante (ad esempio IP masquerading, router Cloud, Cloud NAT, regole firewall VPC o firewall on-premise). Segui i passaggi descritti in questa pagina per verificare la configurazione di routing.

Determinare l'intervallo di indirizzi IP di origine utilizzando il controllo

Prima di configurare router o firewall, utilizza il controllo del mascheramento IP in questo documento e procedi nel seguente modo:

Incolla i contenuti YAML di ip-masq-agent ConfigMap nel campo di configurazione.
Inserisci l'indirizzo IP di destinazione dell'endpoint di destinazione (ad esempio il database on-premise o un servizio internet esterno).
Fai clic su Controlla mascheramento.
Prendi nota dell'output:
- Mascherato: il pacchetto utilizza l'intervallo di indirizzi IP del nodo come origine.
- Non mascherato: il pacchetto utilizza l'intervallo di indirizzi IP del pod come origine.

Configurare la connettività agli endpoint

In base ai risultati del controllo del mascheramento IP, configura i percorsi di rete e i gateway in base al tipo di destinazione.

Endpoint on-premise (VPN o Interconnect)

Cloud NAT non viene utilizzato per la connettività on-premise, ma devi configurare router e firewall in base all'intervallo di indirizzi IP di origine determinato con il controllo del mascheramento IP.

Se il traffico è mascherato (l'origine è l'indirizzo IP del nodo):

Router Cloud: assicurati che gli annunci del router Cloud includano l'intervallo di indirizzi IP primari della subnet del cluster GKE.
Router o firewall on-premise: configura i router e i firewall on-premise per consentire e gestire il traffico in entrata dall'intervallo di indirizzi IP del nodo GKE.

Se il traffico non è mascherato (l'origine è l'indirizzo IP del pod):

Router Cloud: configura gli annunci di route personalizzati sul router Cloud per annunciare l'intervallo di indirizzi IP secondari del pod GKE alla tua rete on-premise.
Router o firewall on-premise: configura le tabelle di routing e i firewall on-premise per consentire il traffico proveniente dall'intervallo di indirizzi IP del pod GKE e assicurati che le route di ritorno vengano annunciate nuovamente al VPC.

Endpoint internet (Cloud NAT)

Quando instradi il traffico verso gli endpoint internet pubblici, devi configurare un gateway Cloud NAT all'interno del VPC.

Nella Cloud de Confiance console, vai alla pagina Cloud NAT.
Seleziona o crea il gateway Cloud NAT.
In Origine Cloud NAT, scegli come il gateway gestisce gli intervalli di subnet GKE:
- Se il traffico è mascherato (l'origine è l'indirizzo IP del nodo): seleziona Intervalli di indirizzi IP primari della subnet. In genere, i deployment GKE commerciali utilizzano questa impostazione per impostazione predefinita.
- Se il traffico non è mascherato (l'origine è l'indirizzo IP del pod): devi selezionare Intervalli di indirizzi IP primari e secondari (o specificare in modo esplicito l'intervallo secondario del pod GKE). Se selezioni solo gli intervalli primari, il traffico internet del pod GKE verrà bloccato.