Panoramica del networking di servizi in GKE

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 le funzionalità di rete di servizi esistenti in GKE.

Panoramica del networking di servizi

Il networking di servizi è la pubblicazione di applicazioni in modo da astrarre 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 in merito a come possono e devono comunicare. Può essere semplice come esporre l'applicazione nel cluster Kubernetes per l'utilizzo dei pod o complicato come instradare il traffico verso l'applicazione da 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 comporta 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. Si tratta della posizione di rete in ascolto del traffico. Ha una rete, una regione specifica (o una subnet all'interno della rete), uno o più indirizzi 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 come elaborare e instradare il traffico. Puoi instradare il traffico a 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 una latenza inferiore e una maggiore resilienza ai tuoi clienti.

  • Backend: i backend del bilanciatore del carico sono definiti dal tipo di endpoint, dalla piattaforma dell'applicazione e dall'integrazione di Service Discovery. GKE utilizza l'integrazione di Service Discovery per aggiornare dinamicamente i backend del bilanciatore del carico man mano che gli endpoint GKE vengono attivati e disattivati.

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 tramite centinaia di punti di presenza Google in tutto il mondo. Questo frontend globale consente di terminare il traffico all'edge, vicino ai client, prima che il bilanciatore del carico lo indirizzi ai backend in un data center Google.

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

Informazioni sul bilanciamento del carico GKE

Per esporre le applicazioni all'esterno di un cluster GKE, GKE fornisce un controller Ingress GKE integrato e un controller Service GKE che eseguono il deployment dei bilanciatori del carico per conto degli utenti GKE. È la stessa 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 per i container utilizzando interfacce di livello superiore e basate su opinioni che rispettano gli standard delle API Ingress e Service.

Il seguente diagramma illustra come 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 nel cluster GKE. I controller Ingress e Service monitorano le risorse di networking GKE (come gli oggetti Ingress) ed eseguono il deployment dei bilanciatori del carico (oltre a indirizzamento 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 GKE diventa un bilanciatore del carico dinamico e autosufficiente con un'interfaccia orientata agli sviluppatori.

Scegliere il metodo per esporre l'applicazione

Quando scegli un metodo per esporre l'applicazione in GKE, la rete client, il protocollo e la regionalità dell'applicazione sono i fattori principali da considerare. Con la suite di controller Ingress e Service di GKE, puoi esporre le tue applicazioni tenendo conto di ciascuno di questi fattori.

Sebbene le sezioni seguenti non trattino tutti gli aspetti del networking delle applicazioni, l'analisi di ciascuno dei seguenti fattori può aiutarti a determinare quali soluzioni sono più adatte alle tue applicazioni. La maggior parte degli ambienti GKE ospita molti tipi diversi di applicazioni, ognuna con requisiti unici, quindi è probabile che ne utilizzerai più di una in un determinato cluster.

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

Rete client

Una rete client si riferisce alla rete da cui i client dell'applicazione accedono all'applicazione. Questo influisce sulla posizione in cui il frontend del bilanciatore del carico deve essere in ascolto. Ad esempio, i client potrebbero trovarsi nello stesso cluster GKE dell'applicazione. In questo caso, accederanno all'applicazione dalla rete del cluster, consentendo loro di utilizzare il bilanciamento del carico ClusterIP nativo di Kubernetes.

I client potrebbero anche essere client di rete interni, che accedono all'applicazione da all'interno della rete Virtual Private Cloud (VPC) o da una rete on-premise tramite un Cloud Interconnect.

I client potrebbero anche essere esterni, che accedono all'applicazione da internet pubblico. Ogni tipo di rete impone una topologia di bilanciamento del carico diversa.

In GKE, puoi scegliere tra bilanciatori del carico interni ed esterni. Interno si riferisce alla rete VPC, che è una rete privata interna non accessibile direttamente da internet. Esterno si riferisce alla rete internet pubblica. I servizi ClusterIP sono interni a un singolo cluster GKE, quindi sono limitati a una rete ancora più piccola della rete VPC.

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

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

1 I cluster GKE che utilizzano il --no-enable-private-nodes flag possono avere nodi con indirizzi IP pubblici e privati, quindi i servizi NodePort possono essere accessibili internamente ed esternamente.

Protocollo

Un protocollo è la lingua che i client parlano con l'applicazione. Le applicazioni vocali, di gioco e a bassa latenza utilizzano in genere TCP o UDP direttamente, richiedendo bilanciatori del carico con un controllo granulare a livello 4. Altre applicazioni parlano HTTP, HTTPS, gRPC o HTTP2 e richiedono bilanciatori del carico con supporto esplicito di questi protocolli. I requisiti del protocollo definiscono ulteriormente quali tipi di metodi di esposizione delle applicazioni sono più adatti.

In GKE, puoi configurare i bilanciatori del carico di livello 4, che instradano il traffico in base alle informazioni di rete come porta e protocollo, e i bilanciatori del carico di livello 7, che sono a conoscenza delle informazioni dell'applicazione come le sessioni client. Ogni bilanciatore del carico diverso è dotato di un supporto di protocollo specifico, 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 		Ingress interno
Ingress esterno
Ingress multi-cluster

Regionalità dell'applicazione

La regionalità dell'applicazione si riferisce al grado di distribuzione dell'applicazione in più di una regione o cluster GKE. L'hosting di una singola istanza di un'applicazione ha 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 posizionare i carichi di lavoro più vicino all'utente finale per una latenza inferiore richiede una consapevolezza multi-cluster e multi-regionale ancora maggiore per il bilanciatore del carico.

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

  • Ambito backend (o ambito cluster): questo ambito si riferisce al fatto che 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 e regioni diversi.

  • Ambito frontend: questo ambito si riferisce al fatto che un indirizzo IP del bilanciatore del carico è in ascolto in una singola regione o in più regioni. Tutti i bilanciatori del carico esterni sono in ascolto su internet, che è intrinsecamente multi-regionale, ma alcuni bilanciatori del carico interni sono in ascolto solo in una singola regione.

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

Ambito 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 delle applicazioni

Le soluzioni precedenti non sono le uniche disponibili per l'esposizione delle applicazioni. Le seguenti soluzioni potrebbero anche essere sostituzioni o complementi validi per i bilanciatori del carico GKE.

Ingress nel cluster

Ingress nel cluster si riferisce ai controller Ingress software i cui proxy Ingress sono ospitati all'interno del cluster Kubernetes stesso. Questo è diverso dai controller Ingress GKE, che ospitano e gestiscono la propria infrastruttura di bilanciamento del carico separatamente dal cluster Kubernetes. Queste soluzioni di terze parti vengono in genere eseguite e gestite autonomamente dall' operatore del cluster. istio-ingressgateway e nginx-ingress sono due esempi di controller Ingress nel cluster open source e di uso comune.

I controller Ingress nel cluster in genere rispettano la specifica Ingress di Kubernetes e forniscono funzionalità e facilità d'uso variabili. Le soluzioni open source probabilmente richiedono una gestione più attenta e un livello di competenze tecniche più elevato, ma potrebbero soddisfare le tue esigenze se forniscono funzionalità specifiche richieste dalle tue applicazioni. Esiste anche un vasto ecosistema di soluzioni Ingress aziendali basate sulla community open source che forniscono funzionalità avanzate e assistenza aziendale.

Gruppi di endpoint di rete (NEG) autonomi

I controller Ingress e Service GKE forniscono 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 avere un controllo diretto e più granulare sul bilanciatore del carico o il bilanciamento del carico tra i backend di container e VM.

I NEG autonomi forniscono questa funzionalità aggiornando dinamicamente gli indirizzi IP dei backend dei pod per un NEG, ma consentono di eseguire il deployment manuale del frontend del bilanciatore del carico. In questo modo si ottiene 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 consente di bilanciare il carico del traffico interno tra i cluster GKE tra le regioni e anche tra container e VM. In questo modo si confonde la linea di demarcazione tra il bilanciamento del carico interno (traffico est-ovest) e l'esposizione delle applicazioni (traffico nord-sud). Grazie alla flessibilità e alla portata dei piani di controllo dei mesh di servizi moderni, è più probabile che mai che il client e il server si trovino nello stesso ambito del mesh di servizi. Le soluzioni Ingress e Service GKE precedenti in genere eseguono il deployment dei bilanciatori del carico proxy intermedi per i client che non hanno i propri proxy sidecar. 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