Esplora la documentazione e i casi d'uso del networking di GKE

Il networking in Google Kubernetes Engine (GKE) copre un ampio insieme di concetti, tra cui pod, servizi, DNS, bilanciamento del carico, sicurezza e gestione degli indirizzi IP. Sebbene la documentazione spieghi in dettaglio ogni funzionalità, può essere difficile sapere da dove iniziare quando si affronta un problema reale.

Questo documento ti aiuta a orientarti nella documentazione sul networking GKE collegando le sfide comuni alle funzionalità e alle sezioni che le risolvono. Ogni caso d'uso presenta uno scenario, identifica la sfida e ti indirizza alla documentazione pertinente. Questo documento è destinato ad architetti cloud, sviluppatori e team operativi che devono comprendere e risolvere le sfide di networking comuni in GKE.

Se hai già familiarità con le sfide comuni del networking e preferisci approfondire direttamente i dettagli tecnici, esplora le seguenti risorse per acquisire le conoscenze di base sul networking GKE:

Caso d'uso: progettare le basi della rete per GKE

In questo caso d'uso, sei un cloud architect che deve progettare una base di rete scalabile, sicura e affidabile per una nuova piattaforma GKE.

Sfida: impedire l'esaurimento degli indirizzi IP

Scenario: la complessità e l'utilizzo della tua applicazione dovrebbero aumentare, quindi devi progettare una rete in grado di scalare per gestire l'aumento del traffico e supportare la crescita di pod, servizi e nodi. Devi anche pianificare l'allocazione degli indirizzi IP per evitare l'esaurimento.

Soluzione: pianifica lo schema di indirizzamento IP in modo da tenere conto del numero di nodi, pod e servizi di cui avrai bisogno. Questo piano prevede la scelta di intervalli di indirizzi IP appropriati per ciascuno, tenendo conto della densità dei pod ed evitando sovrapposizioni con altre reti. Per saperne di più, consulta Gestire la migrazione degli indirizzi IP in GKE.

Sfida: applicare la sicurezza in profondità

Scenario:devi proteggere i perimetri del cluster e applicare regole Zero Trust da pod a pod.

Soluzione:utilizza i criteri firewall per i perimetri dei cluster. Per saperne di più, consulta Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.

Problema: instradare il traffico a diversi tipi di applicazioni

Scenario:devi assicurarti che altri servizi e utenti possano raggiungere diversi tipi di applicazioni, come backend privati e applicazioni HTTP(S) pubbliche.

Soluzione:utilizza i bilanciatori del carico interni per i backend privati. Per le applicazioni HTTP(S) pubbliche, utilizza Ingress o l'API Gateway. Per ulteriori informazioni, consulta Informazioni sul bilanciamento del carico in GKE.

Sfida: utilizza gli strumenti di osservabilità per monitorare e risolvere i problemi dei workload

Scenario: devi risolvere i problemi relativi al traffico di rete e devi comprendere e monitorare i flussi di traffico GKE per diagnosticare i problemi in modo efficace.

Soluzione:implementa strumenti di osservabilità per monitorare e risolvere i problemi relativi al traffico di rete. Per maggiori informazioni, consulta Osservare il traffico utilizzando l'osservabilità di GKE Dataplane V2.

Caso d'uso: esporre un nuovo microservizio

In questo caso d'uso, sei uno sviluppatore che esegue il deployment di un nuovo microservizio in GKE. Devi rendere il microservizio accessibile ad altri servizi nel cluster e, in un secondo momento, a client esterni.

Sfida: fornire un endpoint stabile per la comunicazione tra pod

Scenario:la tua applicazione ha bisogno che i pod comunichino con altri pod, ma gli indirizzi IP dinamici utilizzati dai pod rendono questa comunicazione inaffidabile.

Soluzione:crea un servizio Kubernetes. Un servizio ClusterIP fornisce un indirizzo IP virtuale e un nome DNS stabili, bilanciati tra i pod. Per saperne di più, consulta Informazioni sui servizi Kubernetes.

Sfida: esporre il servizio per l'accesso esterno

Scenario: il microservizio deve essere raggiungibile da internet per una demo.

Soluzione:crea un servizio LoadBalancer. GKE esegue il provisioning di un bilanciatore del carico di rete passthrough esterno regionale con un indirizzo IP pubblico. Per il traffico HTTP(S), valuta la possibilità di utilizzare Ingress o Gateway, che forniscono funzionalità di livello 7. Per saperne di più, consulta l'articolo Informazioni sui servizi LoadBalancer.

Sfida: assegnare un URL permanente e facile da usare

Scenario:il servizio ha bisogno di un nome di dominio stabile per i client.

Soluzione:prenota un indirizzo IP statico e configura il DNS per un dominio personalizzato. Per saperne di più, consulta Configura i nomi di dominio con indirizzi IP statici.

Sfida: gestire il routing avanzato del traffico

Scenario: man mano che la tua applicazione cresce, hai bisogno di un controllo più sofisticato su come viene instradato il traffico. Ad esempio, potresti dover:

  • Ospita più siti web (come api.example.com e shop.example.com) su un unico bilanciatore del carico per contenere i costi.
  • Instrada le richieste a servizi diversi in base al percorso URL (ad esempio, invia / al workload frontend e /api/v1 al workload backend).
  • Proteggi la tua applicazione con HTTPS gestendo i certificati TLS.
  • Esegui il deployment in sicurezza di nuove funzionalità in più fasi utilizzando le release canary, in cui invii una piccola parte del traffico a una nuova versione prima di un'implementazione completa.

Soluzione:utilizza l'API Gateway. L'implementazione dell'API Gateway di GKE fornisce un modo potente e standardizzato per gestire questo tipo di traffico nord-sud, supportando funzionalità avanzate come il routing basato sul percorso, la corrispondenza delle intestazioni e la suddivisione del traffico. Per ulteriori informazioni, consulta Informazioni sull'API Gateway.

Caso d'uso: scalare Service Discovery per un'applicazione in crescita

Man mano che il traffico e la complessità della tua applicazione basata su microservizi aumentano, le query DNS tra i servizi aumentano in modo significativo. Sebbene gli sviluppatori debbano capire come creare applicazioni resilienti in questo ambiente, i team di piattaforma e operazioni sono spesso responsabili dell'implementazione di soluzioni di rete scalabili.

Sfida: abilita la comunicazione da servizio a servizio

Scenario: i pod hanno bisogno di un modo affidabile per individuare altri servizi.

Soluzione: GKE fornisce un servizio DNS in-cluster (ad esempio kube-dns o Cloud DNS) che risolve i nomi DNS stabili per i servizi, consentendo una comunicazione affidabile tra i pod. Per saperne di più, consulta Service discovery e DNS.

Sfida: migliorare le prestazioni del DNS su larga scala

Scenario: l'elevato volume di query causa ritardi nella ricerca.

Soluzione:abilita NodeLocal DNSCache. Ogni nodo memorizza nella cache localmente le query DNS, riducendo la latenza. Per saperne di più, consulta la panoramica della configurazione di NodeLocal DNSCache.

Sfida: fornire il service discovery in tutto il VPC

Scenario: le VM Compute Engine devono accedere ai servizi all'interno del cluster.

Soluzione:esegui l'integrazione con Cloud DNS in modo che i record DNS del servizio vengano risolti nel VPC. Per saperne di più, consulta Utilizzare Cloud DNS per GKE.

Caso d'uso: proteggere un'applicazione multilivello

In questo caso d'uso, fai parte di un team di ingegneria della piattaforma che sta eseguendo il deployment di un'applicazione a tre livelli (frontend, fatturazione, database) e devi applicare la comunicazione zero-trust.

Sfida: applicare regole di traffico rigorose

Scenario:solo servizi specifici devono comunicare tra loro.

Soluzione:abilita l'applicazione dei criteri di rete e applica i criteri default deny, poi definisci regole di autorizzazione esplicite (ad esempio, il frontend consente il traffico alla fatturazione, la fatturazione consente il traffico al database). Per ulteriori informazioni, consulta la pagina Configurare i criteri di rete per le applicazioni.

Sfida: controlla e verifica le policy di rete

Scenario: la sicurezza richiede la prova dell'applicazione e della visibilità.

Soluzione:abilita la registrazione dei criteri di rete per registrare le connessioni consentite e negate. Per saperne di più, consulta Utilizzare la registrazione dei criteri di rete.

Sfida: esporre un servizio in modo privato ai consumer

Scenario: un servizio di backend, come un database o un'API, deve essere accessibile ai consumatori in altre reti VPC senza esporlo alla rete internet pubblica o gestire le complessità del peering VPC.

Soluzione:utilizza Private Service Connect per pubblicare il servizio. I consumer possono quindi creare un endpoint PSC nella propria rete VPC per accedere al servizio in modo privato e sicuro. Per ulteriori informazioni, consulta Esporre servizi con Private Service Connect.

Caso d'uso: ottenere un'alta disponibilità in più cluster

In questo caso d'uso, sei un SRE che esegue carichi di lavoro per un'azienda di e-commerce in più cluster GKE in diverse regioni per migliorare l'affidabilità.

Sfida: attivare la comunicazione cross-cluster

Scenario: i servizi in un cluster devono rilevare e chiamare i servizi in un altro cluster.

Soluzione:utilizza i servizi multi-cluster (MCS) GKE per creare un nome DNS globale e indirizzare automaticamente il traffico ai backend integri. Per maggiori informazioni, consulta Multi-cluster Services.

Sfida: garantire un failover resiliente

Scenario:se un servizio regionale non è più disponibile, il traffico deve essere reindirizzato automaticamente.

Soluzione:MCS fornisce Service Discovery in base allo stato, consentendo ai client di risolvere un singolo nome DNS in un backend integro nel cluster disponibile più vicino. Questo approccio consente un failover resiliente. Per saperne di più, consulta Servizi multicluster.

Caso d'uso: crea un ambiente GKE multi-tenant sicuro ed efficiente

In qualità di membro di un team di ingegneria della piattaforma, fornisci cluster GKE a più team di applicazioni. Devi centralizzare il controllo della rete, conservare gli indirizzi IP e applicare una sicurezza rigorosa.

Sfida: centralizzare il controllo della rete

Scenario: più team di app hanno bisogno di cluster propri, ma la rete deve essere gestita centralmente.

Soluzione:utilizza il VPC condiviso. Le risorse di Networking risiedono in un progetto host, ma i cluster di app vengono eseguiti in progetti di servizio. Per saperne di più, consulta Configurare i cluster con VPC condiviso.

Sfida: gestire in modo efficiente gli indirizzi IP limitati

Scenario: lo spazio degli indirizzi IP è limitato e deve essere utilizzato in modo efficiente.

Soluzione:regola il numero massimo di pod per nodo e, se necessario, utilizza intervalli non RFC 1918 per gli indirizzi IP dei pod. Per saperne di più, consulta Gestire la migrazione degli indirizzi IP in GKE.

Sfida: utilizza un dataplane moderno e sicuro ed esegui il provisioning dei cluster con il nuovo dataplane

Scenari:

  • L'azienda richiede prestazioni elevate e applicazione dei criteri integrata per supportare carichi di lavoro impegnativi e una postura di sicurezza Zero Trust. Ad esempio, potresti eseguire microservizi su larga scala sensibili alla latenza di rete oppure potresti dover applicare limiti di sicurezza rigorosi tra le applicazioni in un cluster multi-tenant per soddisfare i requisiti di conformità normativa.
  • I cluster devono essere configurati per utilizzare un dataplane di rete moderno per prestazioni e sicurezza elevate e devono essere implementati all'interno della struttura di rete gestita centralmente dell'organizzazione.

Soluzione:utilizza GKE Dataplane V2, basato su eBPF e che offre prestazioni elevate e applicazione integrata delle policy di rete. Per maggiori informazioni, consulta GKE Dataplane V2.

Caso d'uso: osservare e risolvere i problemi relativi al traffico

In qualità di SRE, stai esaminando il motivo per cui un servizio di pagamento non riesce a connettersi a un servizio di pagamento.

Sfida: risolvi i problemi di connettività

Scenario: i pacchetti vengono eliminati, ma la causa non è chiara.

Soluzione: abilita l'osservabilità di GKE Dataplane V2. Metriche come hubble_drop_total confermano che i pacchetti vengono rifiutati. Per saperne di più, consulta la sezione Risolvere i problemi con Hubble.

Sfida: individuare la causa principale dei pacchetti eliminati

Scenario: dopo aver verificato che i pacchetti di rete vengono eliminati (ad esempio, utilizzando hubble_drop_total), identifica quale specifica norma di rete blocca il traffico tra i servizi.

Soluzione:utilizza l'interfaccia a riga di comando o la UI di Hubble per tracciare i flussi. L'interfaccia utente di Hubble fornisce una rappresentazione visiva del traffico, evidenziando la policy configurata in modo errato che nega la connessione. Questa visualizzazione consente al team di individuare rapidamente la causa principale del problema e correggere il policy. Per maggiori informazioni, consulta Osservare il traffico utilizzando l'osservabilità di GKE Dataplane V2.

Caso d'uso end-to-end: esegui il deployment e scala un'applicazione di vendita al dettaglio sicura

In questo scenario end-to-end, un team di ingegneria della piattaforma crea una piattaforma GKE standardizzata per più team di applicazioni. Il team esegue il deployment e ottimizza un'applicazione di vendita al dettaglio a tre livelli (frontend, fatturazione, database). Questo processo include la protezione, lo scaling, il miglioramento delle prestazioni per i carichi di lavoro di machine learning e l'integrazione di appliance di sicurezza avanzate.

Il seguente diagramma illustra l'architettura end-to-end di un'applicazione di vendita al dettaglio sicura e multilivello di cui è stato eseguito il deployment su GKE. L'architettura si evolve in diverse fasi:

  • Fase 1: crea una configurazione di base utilizzando il VPC condiviso e GKE Dataplane V2.
  • Fase 2:esponi l'applicazione utilizzando l'API Gateway e i servizi multicluster per l'alta disponibilità.
  • Fase 3: accelera le attività di ML utilizzando gVNIC e il networking di livello 1.
  • Fase 4: esegui il deployment di appliance di sicurezza avanzate utilizzando il supporto multi-rete.
Diagramma che mostra l'architettura end-to-end per un'applicazione di vendita al dettaglio sicura e multilivello su GKE, che illustra i componenti di networking in sei fasi di deployment e scalabilità.
Figura 1. Un'architettura end-to-end per un'applicazione di vendita al dettaglio sicura e multilivello su GKE, che mette in evidenza i componenti di networking chiave utilizzati in ogni fase del deployment e dello scaling. I dettagli di ogni fase sono descritti nelle sezioni seguenti.

Fase 1: crea le basi della piattaforma

Sfida: centralizzare il networking per più team di applicazioni e allocare indirizzi IP sufficienti per gestire lo scaling.

Soluzione:

Fase 2: esegui il deployment e proteggi l'applicazione

Sfida: garantire una comunicazione service-to-service affidabile e applicare la sicurezza zero trust.

Soluzione:

  • Crea servizi ClusterIP per endpoint interni stabili.
  • Applica norme di rete con una baseline di negazione predefinita e regole di autorizzazione esplicite.

Fase 3: esponi l'applicazione e scalala per la crescita

Sfida:fornire accesso esterno e ridurre la latenza di ricerca DNS all'aumentare del traffico.

Soluzione:

Fase 4: ottieni l'alta disponibilità e risolvi i problemi

Sfida:assicurati il failover regionale ed esegui il debug del traffico eliminato.

Soluzione:

Fase 5: accelera i carichi di lavoro di machine learning

Sfida:eliminare i colli di bottiglia della rete per l'addestramento di modelli basati su GPU.

Soluzione:

  • Attiva gVNIC per una larghezza di banda maggiore.
  • Configura il networking di livello 1 sui nodi critici per la massima velocità effettiva.

Fase 6: esegui il deployment di appliance di sicurezza avanzate

Sfida:implementare un firewall e un IDS di terze parti con gestione e traffico del piano dati separati a latenza bassissima.

Soluzione:

Passaggi successivi