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

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

Questo documento ti aiuta a consultare la documentazione sul networking di 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 di networking comuni e preferisci approfondire direttamente i dettagli tecnici, esplora le seguenti risorse per creare le tue conoscenze di base sul networking di GKE:

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

In questo caso d'uso, sei un architetto cloud 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 include la scelta di intervalli di indirizzi IP appropriati per ciascuno, tenendo conto della densità dei pod ed evitando sovrapposizioni con altre reti. Per ulteriori informazioni, consulta Gestire la migrazione degli indirizzi IP in GKE.

Sfida: applicare la sicurezza di difesa 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 ulteriori informazioni, consulta Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.

Sfida: 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: utilizzare gli strumenti di osservabilità per monitorare e risolvere i problemi dei carichi di lavoro

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

Soluzione: implementa gli strumenti di osservabilità per monitorare e risolvere i problemi relativi al traffico di rete. Per ulteriori 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, ai client esterni.

Sfida: fornire un endpoint stabile per la comunicazione da pod a pod

Scenario: la tua applicazione richiede 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 stabile e un nome DNS, con bilanciamento del carico tra i pod. Per ulteriori informazioni, 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 ulteriori informazioni, consulta Informazioni sui servizi LoadBalancer.

Sfida: assegnare un URL permanente e di facile utilizzo

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

Soluzione: prenota un indirizzo IP statico e configura il DNS per un dominio personalizzato. Per ulteriori informazioni, consulta Configurare i nomi di dominio con indirizzi IP statici.

Sfida: gestire l'instradamento avanzato del traffico

Scenario: con la crescita dell'applicazione, hai bisogno di un controllo più sofisticato sull'instradamento del traffico. Ad esempio, potresti dover:

  • Ospitare più siti web (ad esempio api.example.com e shop.example.com) su un singolo bilanciatore del carico per ridurre i costi.
  • Instradare le richieste a servizi diversi in base al percorso dell'URL (ad esempio, inviare / al carico di lavoro frontend e /api/v1 al carico di lavoro backend).
  • Proteggere l'applicazione con HTTPS gestendo i certificati TLS.
  • Eseguire il deployment in sicurezza di nuove funzionalità in fasi utilizzando le release canary, in cui invii una piccola parte del traffico a una nuova versione prima di un rollout completo.

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 l'instradamento 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

Con la crescita del traffico e della complessità dell'applicazione basata su microservizi, le query DNS tra i servizi aumentano in modo significativo. Sebbene gli sviluppatori debbano comprendere come creare applicazioni resilienti in questo ambiente, i team di piattaforma e operativi sono spesso responsabili dell'implementazione di soluzioni di networking scalabili.

Sfida: abilitare la comunicazione da servizio a servizio

Scenario: i pod richiedono 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 da pod a pod. Per ulteriori informazioni, consulta Service Discovery e DNS.

Sfida: migliorare le prestazioni DNS su larga scala

Scenario: un volume elevato di query causa ritardi nelle ricerche.

Soluzione: abilita NodeLocal DNSCache. Ogni nodo memorizza nella cache le query DNS localmente, riducendo la latenza. Per ulteriori informazioni, consulta Panoramica della configurazione di NodeLocal DNSCache.

Sfida: fornire Service Discovery nel VPC

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

Soluzione: integra Cloud DNS in modo che i record DNS del servizio vengano risolti nel VPC. Per ulteriori informazioni, consulta Utilizzare Cloud DNS per GKE.

Caso d'uso: proteggere un'applicazione a più livelli

In questo caso d'uso, fai parte di un team di ingegneria della piattaforma che esegue 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, quindi 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 Configurare i criteri di rete per le applicazioni.

Sfida: controllare e verificare i criteri 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 ulteriori informazioni, consulta Utilizzare la registrazione delle policy di rete.

Sfida: esporre un servizio in privato ai consumer

Scenario: un servizio di backend, come un database o un'API, deve essere accessibile ai consumer 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 nel proprio VPC per accedere al tuo servizio in modo privato e sicuro. Per ulteriori informazioni, consulta Esporre i servizi con Private Service Connect.

Caso d'uso: ottenere un'alta affidabilità su 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 regioni diverse per migliorare l'affidabilità.

Sfida: abilitare la comunicazione tra cluster

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

Soluzione: utilizza i servizi multi-cluster (MCS) di GKE per creare un nome DNS globale e instradare automaticamente il traffico ai backend integri. Per ulteriori informazioni, consulta Servizi multi-cluster.

Sfida: garantire un failover resiliente

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

Soluzione: MCS fornisce Service Discovery con riconoscimento dell'integrità, 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 ulteriori informazioni, consulta Servizi multi-cluster.

Caso d'uso: creare 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 dei propri cluster, ma il networking deve essere gestito centralmente.

Soluzione: utilizza il VPC condiviso. Le risorse di networking risiedono in un progetto host, ma i cluster di app vengono eseguiti nei progetti di servizio. Per ulteriori informazioni, consulta Configurare i cluster con il 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 ulteriori informazioni, consulta Gestire la migrazione degli indirizzi IP in GKE.

Sfida: utilizzare un piano dati moderno e sicuro ed eseguire il provisioning dei cluster con il nuovo piano dati

Scenari:

  • L'azienda richiede prestazioni elevate e l'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à legale.
  • I cluster devono essere configurati per utilizzare un piano dati di networking moderno per prestazioni e sicurezza elevate e devono essere sottoposti a deployment all'interno della struttura di rete gestita centralmente dell'organizzazione.

Soluzione: utilizza GKE Dataplane V2, che è basato su eBPF e fornisce prestazioni elevate e applicazione dei criteri di rete integrata. Per ulteriori informazioni, consulta GKE Dataplane V2.

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

In qualità di SRE, stai indagando sul motivo per cui un servizio di checkout non riesce a connettersi a un servizio di pagamento.

Sfida: risolvere 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 negati. Per ulteriori informazioni, consulta Risolvere i problemi con Hubble.

Sfida: individuare la causa principale dei pacchetti eliminati

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

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

Caso d'uso end-to-end: eseguire il deployment e scalare 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, la scalabilità, 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 a più livelli sottoposta a 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 multi-cluster per la disponibilità elevata.
  • 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 a più livelli su GKE, che evidenzia i componenti di networking chiave utilizzati in ogni fase del deployment e della scalabilità. I dettagli di ogni fase sono descritti nelle sezioni seguenti.

Fase 1: crea le basi della piattaforma

Sfida: centralizza il networking per più team di applicazioni e alloca indirizzi IP sufficienti per gestire la scalabilità.

Soluzione:

Fase 2: esegui il deployment e proteggi l'applicazione

Sfida: garantisci una comunicazione affidabile da servizio a servizio e applica la sicurezza zero-trust.

Soluzione:

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

Sfida: fornisci l'accesso esterno e riduci la latenza di ricerca DNS con l'aumento del traffico.

Soluzione:

Fase 4: ottieni un'alta affidabilità e risolvi i problemi

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

Soluzione:

Fase 5: accelera i carichi di lavoro di machine learning

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

Soluzione:

Fase 6: esegui il deployment di appliance di sicurezza avanzate

Sfida: esegui il deployment di un firewall e di un IDS di terze parti con traffico di gestione e piano dati separato a latenza molto bassa.

Soluzione:

Passaggi successivi