Panoramica del networking di servizi

Questa pagina descrive come eseguire il deployment dei servizi in Google Kubernetes Engine (GKE). Utilizza questa pagina come guida per comprendere meglio gli aspetti del networking di servizi e delle funzionalità di rete di servizi esistenti in GKE.

Panoramica del networking di servizi

Il networking di servizi è la pubblicazione di applicazioni in un modo che astrae la proprietà, l'implementazione o l'ambiente sottostante dell'applicazione utilizzato dai client. Nella sua forma più semplice, un servizio è un endpoint sicuro, coerente e disponibile attraverso il quale si accede a un'applicazione.

I client e le applicazioni hanno esigenze diverse in termini di come possono e devono comunicare. Può essere semplice, come l'esposizione dell'applicazione nel cluster Kubernetes da utilizzare per i pod, o l'instradamento del traffico verso la tua applicazione da client internet in tutto il mondo. GKE offre vari modi per esporre le applicazioni come servizi adatti ai tuoi casi d'uso unici.

Elementi di un servizio

L'esposizione di un'applicazione ai client implica tre elementi chiave di un servizio:

  • Frontend: il frontend del bilanciatore del carico definisce l'ambito in cui i client possono accedere e inviare il traffico al bilanciatore del carico. Questa è la posizione della rete che ascolta il traffico. Ha una rete, una regione specifica (o una subnet all'interno della rete), uno o più IP nella rete, porte, protocolli specifici e certificati TLS presentati per stabilire connessioni sicure.

  • Routing e bilanciamento del carico: il routing e il bilanciamento del carico definiscono il modo in cui elabori e instrada il traffico. Puoi instradare il traffico ai servizi in base a parametri come protocolli, intestazioni HTTP e percorsi HTTP. A seconda del bilanciatore del carico utilizzato, potrebbe bilanciare il traffico per fornire minore latenza e maggiore resilienza ai tuoi clienti.

  • Backend: i backend dei bilanciatori del carico sono definiti in base al tipo di endpoint, piattaforma dell'applicazione e integrazione di Service Discovery di backend. GKE utilizza l'integrazione di Service Discovery per aggiornare i backend del bilanciatore del carico in modo dinamico man mano che gli endpoint GKE si presentano.

Il seguente diagramma illustra questi concetti per il traffico interno ed esterno:

In questo diagramma, il bilanciatore del carico delle applicazioni esterno è in ascolto del traffico sulla rete internet pubblica attraverso centinaia di punti di presenza Google in tutto il mondo. Questo frontend globale consente di terminare il traffico a livello perimetrale, vicino ai client, prima di bilanciare il carico del traffico verso i propri backend in un data center Google.

L'Application Load Balancer interno rimane in ascolto nell'ambito della tua rete VPC, consentendo l'esecuzione interna delle comunicazioni private. Queste proprietà del bilanciatore del carico le rendono adatte a diversi tipi di casi d'uso delle applicazioni.

Informazioni sul bilanciamento del carico di GKE

Per esporre le applicazioni all'esterno di un cluster GKE, GKE fornisce un controller Ingress GKE e un controller di servizio GKE integrati che eseguono il deployment dei bilanciatori del carico per conto degli utenti GKE. È uguale all'infrastruttura di bilanciamento del carico delle VM, ma il suo ciclo di vita è completamente automatizzato e controllato da GKE. I controller di rete GKE forniscono il bilanciamento del carico IP dei pod nativo del container utilizzando interfacce di livello superiore opinate conformi agli standard delle API Ingress e Service.

Il seguente diagramma illustra il modo in cui i controller di rete GKE automatizzano la creazione dei bilanciatori del carico:

Come mostrato nel diagramma, un amministratore dell'infrastruttura o dell'app esegue il deployment di un manifest dichiarativo sul proprio cluster GKE. I controller di servizio e Ingress monitorano le risorse di networking di GKE (ad esempio gli oggetti Ingress) ed eseguono il deployment di bilanciatori del carico (oltre a indirizzi IP, regole firewall e così via) in base al manifest.

Il controller continua a gestire il bilanciatore del carico e i backend in base alle modifiche all'ambiente e al traffico. Per questo motivo, il bilanciamento del carico di GKE diventa un bilanciatore del carico dinamico e autosufficiente con un'interfaccia orientata agli sviluppatori.

Scelta del metodo per esporre l'applicazione

Quando scegli un metodo per esporre l'applicazione in GKE, la rete del client, il protocollo e la regione dell'applicazione sono i fattori principali da considerare. Con la suite di controller Ingress e di servizio di GKE, puoi esporre le tue applicazioni tenendo a mente ognuno di questi fattori.

Anche se le sezioni seguenti non trattano tutti gli aspetti del networking delle applicazioni, l'analisi di ciascuno dei fattori seguenti può aiutarti a determinare quali sono le soluzioni migliori per le tue applicazioni. La maggior parte degli ambienti GKE ospita molti tipi diversi di applicazioni, tutte con requisiti univoci, quindi è probabile che ne utilizzerai più di una in un dato cluster.

Per un confronto dettagliato delle funzionalità di Ingress, consulta Configurazione di Ingress.

Rete client

Una rete client è la rete da cui i client dell'applicazione accedono all'applicazione. Questa operazione determina dove il frontend del bilanciatore del carico deve rimanere in ascolto. Ad esempio, i client potrebbero trovarsi nello stesso cluster GKE dell'applicazione. In questo caso, accederanno alla tua applicazione dall'interno della rete del cluster, consentendo di utilizzare il bilanciamento del carico ClusterIP nativo di Kubernetes.

I client potrebbero anche essere client di rete interni che accedono all'applicazione dal Virtual Private Cloud (VPC) o da una rete on-premise attraverso Cloud Interconnect.

I client potrebbero anche essere esterni e che accedono alla tua applicazione dalla rete internet pubblica. Ogni tipo di rete determina una diversa topologia di bilanciamento del carico.

In GKE puoi scegliere tra bilanciatori del carico interni ed esterni. Interna si riferisce alla rete VPC, che è una rete privata interna non accessibile direttamente da internet. Per esterno si intende la rete internet pubblica. I servizi ClusterIP sono interni a un singolo cluster GKE, quindi hanno come ambito una rete ancora più piccola rispetto alla rete VPC.

La tabella seguente fornisce una panoramica delle soluzioni disponibili per le reti interne ed esterne.

Tipo di rete Soluzioni disponibili
Interna Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
Ingress interno
Esterna Servizio NodePort1
Servizio LoadBalancer esterno
Ingress esterno
Ingress multi-cluster

1 I cluster GKE pubblici forniscono indirizzi IP pubblici e privati a ciascun nodo GKE, pertanto i servizi NodePort possono essere accessibili interni ed esterni.

Protocollo

Un protocollo è la lingua parlata dai client all'applicazione. Le applicazioni vocali, di gioco e a bassa latenza di solito usano direttamente TCP o UDP, richiedendo bilanciatori del carico con controllo granulare al livello 4. Altre applicazioni utilizzano HTTP, HTTPS, gRPC o HTTP2 e richiedono bilanciatori del carico con il supporto esplicito di questi protocolli. I requisiti di protocollo definiscono ulteriormente i tipi di metodi di esposizione delle applicazioni più adatti.

In GKE puoi configurare bilanciatori del carico di livello 4, che instradano il traffico in base a informazioni di rete come porta e protocollo, e bilanciatori del carico di livello 7, che sono a conoscenza delle informazioni sull'applicazione come le sessioni client. Ogni bilanciatore del carico è compatibile con protocolli specifici, come illustrato nella tabella seguente:

Base Protocolli Soluzioni disponibili
L4 TCP
UDP		 Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
Servizio LoadBalancer esterno
L7 HTTP
HTTPS
HTTP2 		Ingress interno
Ingress esterno
Ingress multi-cluster

Regionalità dell'applicazione

La regione dell'applicazione si riferisce alla misura in cui l'applicazione è distribuita in più di una regione o di un cluster GKE. L'hosting di una singola istanza di un'applicazione presenta requisiti diversi rispetto all'hosting di istanze ridondanti di un'applicazione in due cluster GKE indipendenti. L'hosting di un'applicazione distribuita geograficamente in cinque cluster GKE per collocare i carichi di lavoro più vicino all'utente finale per una latenza minore richiede ancora più consapevolezza multi-cluster e multiregionale per il bilanciatore del carico.

Puoi suddividere la regione delle soluzioni di bilanciamento del carico GKE in due aree:

  • Ambito di backend (o ambito del cluster): questo ambito si riferisce alla possibilità di inviare traffico ai backend su più cluster GKE tramite un bilanciatore del carico. Ingress multi-cluster ha la possibilità di esporre un singolo indirizzo IP virtuale che indirizza il traffico ai pod da diversi cluster e regioni diverse.

  • Ambito di frontend: questo ambito si riferisce al fatto che un IP del bilanciatore del carico ascolti all'interno di una singola regione o in più regioni. Tutti i bilanciatori del carico esterni restano in ascolto su internet, che è intrinsecamente multiregionale, ma alcuni bilanciatori del carico interni ascoltano solo all'interno di un'unica regione.

La seguente tabella suddivide le soluzioni di bilanciamento del carico di GKE in queste due dimensioni.

Ambito di backend
(ambito cluster)		 Soluzioni disponibili
Cluster singolo Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
Servizio LoadBalancer esterno
Ingress interno
Ingress esterno
Cluster multipli Ingress multi-cluster
Ambito frontend Soluzioni disponibili
Regionale Servizio ClusterIP
Ingress interno
Globale Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
Servizio LoadBalancer esterno
Ingress esterno
Ingress multi-cluster

Altre soluzioni per l'esposizione alle applicazioni

Le soluzioni precedenti non sono le uniche disponibili per l'esposizione delle applicazioni. Le seguenti soluzioni potrebbero anche essere sostituibili o complementari ai bilanciatori del carico GKE.

Ingress nel cluster

Il termine Ingress nel cluster è un controller software Ingress i cui proxy Ingress sono ospitati all'interno del cluster Kubernetes stesso. È diverso dai controller GKE Ingress, che ospitano e gestiscono l'infrastruttura di bilanciamento del carico separatamente dal cluster Kubernetes. Queste soluzioni di terze parti vengono generalmente sottoposte a deployment autonomo e gestite autonomamente dall'operatore del cluster. istio-ingressgateway e nginx-ingress sono due esempi di controller Ingress in-cluster open source comunemente utilizzati.

I controller Ingress nel cluster sono generalmente conformi alle specifiche di Kubernetes Ingress e offrono capacità diverse e facilità d'uso. È probabile che le soluzioni open source richiedano una gestione più approfondita e un livello superiore di competenze tecniche, ma potrebbero soddisfare le tue esigenze se forniscono funzionalità specifiche richieste dalle applicazioni. Esiste inoltre un vasto ecosistema di soluzioni Ingress aziendali create attorno alla community open source che offrono funzionalità avanzate e assistenza per le aziende.

Gruppi di endpoint di rete (NEG) autonomi

I controller GKE Ingress e Service offrono metodi automatizzati, dichiarativi e nativi di Kubernetes per il deployment di Cloud Load Balancing. Esistono anche casi d'uso validi per il deployment manuale dei bilanciatori del carico per i backend GKE, ad esempio per avere un controllo diretto e più granulare sul bilanciatore del carico o per il bilanciamento del carico tra backend di container e VM.

I NEG autonomi offrono questa possibilità aggiornando gli IP del backend del pod in modo dinamico per un NEG, ma consentono il deployment manuale del frontend del bilanciatore del carico. Ciò fornisce il controllo massimo e diretto del bilanciatore del carico, mantenendo i backend dinamici controllati dal cluster GKE.

Mesh di servizi

I mesh di servizi forniscono il bilanciamento del carico lato client tramite un piano di controllo centralizzato. Cloud Service Mesh e Cloud Service Mesh consentono di bilanciare il carico del traffico interno tra i cluster GKE, tra regioni e anche tra container e VM. In questo modo viene sfocato la linea tra il bilanciamento del carico interno (traffico est-ovest) e l'esposizione delle applicazioni (traffico nord-sud). Grazie alla flessibilità e alla portata dei moderni piani di controllo della rete di servizi, è più probabile che mai avere sia il client che il server nello stesso ambito del mesh di servizi. Le precedenti soluzioni GKE Ingress e Service di solito distribuiscono bilanciatori del carico proxy medi per i client che non hanno proxy sidecar propri. Tuttavia, se un client e un server si trovano nella stessa rete mesh, l'esposizione dell'applicazione può essere gestita utilizzando il bilanciamento del carico del mesh anziché del proxy centrale.

Passaggi successivi