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 i facet del networking dei servizi e le funzionalità della rete dei 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 utilizzata dai client. Nella sua forma più semplice, un servizio è un endpoint sicuro, coerente e disponibile tramite il quale si accede a un'applicazione.

I client e le applicazioni hanno esigenze diverse relative al modo in cui possono e devono comunicare. Può essere semplice come esporre la tua applicazione nel cluster Kubernetes per consentire ai pod di utilizzare, oppure come instradare il traffico alla tua applicazione dai client internet in tutto il mondo. GKE offre molti 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 prevede tre elementi chiave di un servizio:

  • Frontend: il frontend del bilanciatore del carico definisce l'ambito in cui i client possono accedere e inviare traffico al bilanciatore del carico. Questa è la posizione della rete che ascolta il traffico. È costituito da 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 le modalità di elaborazione e instradamento del 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 clienti.

  • Backend: i backend del bilanciatore del carico sono definiti in base al tipo di endpoint, alla piattaforma applicativa e all'integrazione Service Discovery di backend. GKE usa l'integrazione di Service Discovery per aggiornare i backend del bilanciatore del carico in modo dinamico man mano che si verificano gli endpoint GKE.

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

In questo diagramma, l'Application Load Balancer esterno rileva il 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 rispettivi backend in un data center Google.

Il bilanciatore del carico delle applicazioni interno rimane in ascolto nell'ambito della rete VPC, consentendo le comunicazioni private di avvenire internamente. Queste proprietà le rendono adatte a diversi tipi di casi d'uso di applicazioni.

Informazioni sul bilanciamento del carico di GKE

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

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

Come visualizzato nel diagramma, un amministratore di infrastruttura o app esegue il deployment di un manifest dichiarativo sul proprio cluster GKE. I controller in entrata e di servizio controllano le risorse di networking GKE (ad esempio oggetti Ingress) ed eseguono il deployment dei 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 ambientali e del traffico. Per questo motivo, il bilanciamento del carico di GKE diventa un bilanciatore del carico dinamico e autosufficiente con un'interfaccia orientata allo sviluppatore.

Scelta del metodo per esporre l'applicazione

Quando scegli un metodo per esporre la tua applicazione in GKE, la rete client, il protocollo e la regione dell'applicazione sono i fattori fondamentali da considerare. Con la suite di controller Ingress e di servizio di GKE, puoi esporre le tue applicazioni in base a ciascuno di questi fattori.

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

Per un confronto dettagliato delle funzionalità in entrata, consulta l'articolo sulla configurazione di Ingress.

Rete client

Per rete client si intende la rete da cui i client dell'applicazione accedono all'applicazione. Questo influisce su dove il frontend del bilanciatore del carico deve essere in ascolto. Ad esempio, i client potrebbero trovarsi all'interno dello stesso cluster GKE dell'applicazione. In questo caso, accederanno alla tua applicazione dall'interno della rete del cluster, in modo da poter utilizzare il bilanciamento del carico ClusterIP nativo di Kubernetes.

I client possono anche essere client di rete interni, che accedono all'applicazione dall'interno del VPC (Virtual Private Cloud) o da una rete on-premise su Cloud Interconnect.

I client possono anche essere esterni e possono accedere all'applicazione dalla rete internet pubblica. Ogni tipo di rete determina una topologia di bilanciamento del carico diversa.

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. Con 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 seguente tabella fornisce una panoramica delle soluzioni disponibili per le reti interne ed esterne.

Tipo di rete Soluzioni disponibili
IP Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
In entrata interna
Esterno Servizio NodePort1
Servizio LoadBalancer esterno
In entrata esterna
In entrata multi-cluster

1 I cluster GKE pubblici forniscono indirizzi IP pubblici e privati a ciascun nodo GKE, quindi i servizi NodePort possono essere accessibili internamente ed esternamente.

Protocollo

Un protocollo è la lingua parlata dai clienti 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 parlano HTTP, HTTPS, gRPC o HTTP2 e richiedono bilanciatori del carico con 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 riconoscono le informazioni delle applicazioni come le sessioni client. Ogni bilanciatore del carico prevede un supporto specifico per i protocolli, come mostrato nella tabella seguente:

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

Regione dell'applicazione

La regione dell'applicazione indica il livello di distribuzione dell'applicazione in più regioni o cluster GKE. L'hosting di una singola istanza di un'applicazione ha requisiti diversi rispetto all'hosting di istanze ridondanti di un'applicazione su due cluster GKE indipendenti. L'hosting di un'applicazione distribuita in modo geografico su cinque cluster GKE per collocare i carichi di lavoro più vicino all'utente finale per una latenza inferiore richiede ancora più consapevolezza multi-cluster e più regioni per il bilanciatore del carico.

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

  • Ambito del backend (o cluster): questo ambito indica se un bilanciatore del carico può inviare traffico ai backend in più cluster GKE. Ingress multi-cluster ha la capacità di esporre un singolo indirizzo IP virtuale che indirizza il traffico ai pod da cluster diversi e regioni diverse.

  • Ambito di frontend: questo ambito si riferisce a se un IP del bilanciatore del carico rimane in ascolto all'interno di una singola regione o in più regioni. Tutti i bilanciatori del carico esterni sono in ascolto su internet, che è di per sé multiregionale, ma alcuni bilanciatori del carico interni sono in ascolto solo all'interno di una singola regione.

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

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

Altre soluzioni per l'esposizione delle applicazioni

Le soluzioni precedenti non sono le uniche disponibili per esporre le applicazioni. Le seguenti soluzioni potrebbero anche essere sostituti o complementari attuabili ai bilanciatori del carico GKE.

Ingress nel cluster

Il termine Ingress nel cluster si riferisce ai controller Ingress software con i proxy Ingress ospitati all'interno del cluster Kubernetes. È diverso dai controller GKE Ingress, che ospitano e gestiscono la propria infrastruttura di bilanciamento del carico separatamente dal cluster Kubernetes. Queste soluzioni di terze parti sono generalmente gestite in modo autonomo dall'operatore di cluster. istio-ingressgateway e nginx-ingress sono due esempi di controller Ingress nel cluster open source di uso comune.

I controller Ingress nel cluster in genere si conformano alle specifiche di Kubernetes Ingress, offrono capacità variabili e facilità d'uso. È probabile che le soluzioni open source richiedano una gestione più approfondita e un livello più elevato di competenze tecniche, ma potrebbero soddisfare le tue esigenze se forniscono funzionalità specifiche richieste dalle tue applicazioni. Esiste anche un vasto ecosistema di soluzioni Ingress di livello enterprise, basate sulla community open source, che offrono funzionalità avanzate e supporto aziendale.

Gruppi di endpoint di rete (NEG) autonomi

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

I NEG autonomi forniscono questa capacità aggiornando gli IP del backend dei 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 al contempo 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. Traffic Director e Anthos Service Mesh consentono di bilanciare il carico del traffico interno nei cluster GKE, in più regioni e anche tra container e VM. Questo sfoca la linea tra il bilanciamento del carico interno (traffico est-ovest) e l'esposizione delle applicazioni (traffico nord-sud). Grazie alla flessibilità e alla copertura dei moderni piani di controllo del mesh di servizi, è più probabile che mai che sia il client che il server rientrano nello stesso ambito del mesh di servizi. Le precedenti soluzioni GKE in entrata e di servizio in genere eseguono il deployment di bilanciatori del carico proxy medi per i client che non hanno i propri proxy collaterali. Tuttavia, se un client e un server si trovano nello stesso mesh, l'esposizione dell'applicazione può essere gestita utilizzando il mesh anziché il bilanciamento del carico proxy intermedio.

Passaggi successivi