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 di networking di GKE collegando i problemi comuni alle funzionalità e alle sezioni che li risolvono. Ogni caso d'uso presenta uno scenario, identifica la sfida e rimanda 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 acquisire le conoscenze di base sul networking GKE:

Caso d'uso: progetta la base di 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 scalabile in grado di 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.

Sfida: applica la sicurezza defense in depth

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

Soluzione:utilizza le policy del firewall per i perimetri dei cluster. Per saperne di più, consulta Controllare la comunicazione tra pod e servizi utilizzando le policy 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 l'API Ingress o Gateway. Per saperne di più, consulta Informazioni sul bilanciamento del carico in GKE.

Sfida: utilizza gli strumenti di osservabilità per monitorare e risolvere i problemi relativi ai 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.

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 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, con bilanciamento del carico tra i pod. Per saperne di più, consulta Informazioni sui servizi Kubernetes.

Sfida: esporre il servizio per l'accesso esterno

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

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 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 sul modo in cui 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 ridurre i costi.
  • Instrada le richieste a servizi diversi in base al percorso dell'URL (ad esempio, invio di / al workload frontend e di /api/v1 al workload backend).
  • Proteggi la tua applicazione con HTTPS gestendo i certificati TLS.
  • Esegui il deployment in modo sicuro di nuove funzionalità in più fasi utilizzando le versioni 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 il 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: abilitare 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 (come kube-dns o Cloud DNS) che risolve i nomi DNS stabili per i servizi, consentendo una comunicazione pod-pod affidabile. Per saperne di più, consulta Service discovery e DNS.

Sfida: migliorare le prestazioni del DNS su larga scala

Scenario: un volume elevato di query causa ritardi nella ricerca.

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

Sfida: fornire il Service Discovery nel VPC

Scenario: le VM di 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 maggiori informazioni, consulta Utilizza 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 del traffico rigorose

Scenario: solo servizi specifici devono comunicare tra loro.

Soluzione:abilita l'applicazione delle policy di rete e applica le policy 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 saperne di più, consulta Configura le policy 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 il logging delle policy di rete per registrare le connessioni consentite e negate. Per saperne di più, consulta Utilizzare la registrazione delle policy di rete.

Sfida: esporre un servizio privatamente ai consumatori

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 servizio in modo privato e sicuro. Per saperne di più, consulta Esporre servizi con Private Service Connect.

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 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 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.

Sfida: utilizzare un dataplane moderno e sicuro ed eseguire 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 o potresti dover applicare confini 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 distribuiti 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 dei criteri di rete. Per maggiori informazioni, consulta 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 l'ottimizzazione di 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 workload 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 multi-livello 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.
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 comunicazioni affidabili da servizio a servizio e applicare la sicurezza Zero Trust.

Soluzione:

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

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

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

Soluzione:

Passaggi successivi