Panoramica del networking di servizi

In questa pagina viene descritto come eseguire il deployment dei servizi in Google Kubernetes Engine (GKE). Utilizza questa pagina come guida per comprendere meglio le varie sfaccettature del networking dei servizi e le funzionalità di rete di servizio esistenti in GKE.

Panoramica del networking di servizi

La creazione di reti di servizi è la pubblicazione di applicazioni in modo da astrarre la proprietà, l'implementazione o l'ambiente sottostanti 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 termini di come possono e devono comunicare. Può essere semplice come esporre l'applicazione nel cluster Kubernetes da utilizzare per i pod, o complicato come il routing del traffico verso la tua applicazione da client internet in tutto il mondo. GKE offre molti modi per esporre le applicazioni come servizi per i tuoi casi d'uso unici.

Elementi di un servizio

L'esposizione di un'applicazione ai client coinvolge 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 è in ascolto per il traffico. Dispone di 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 a elaborare e indirizzare il traffico. Puoi instradare il traffico verso i servizi in base a parametri come protocolli, intestazioni HTTP e percorsi HTTP. In base a al bilanciatore del carico che utilizzi, potrebbe bilanciare il traffico per fornire una latenza minore e una maggiore resilienza nei confronti dei tuoi clienti.

  • Backend: i backend del bilanciatore del carico sono definiti dal tipo di endpoint, dalla piattaforma di applicazioni e dall'integrazione del rilevamento dei servizi di backend. GKE utilizza l'integrazione di Service Discovery per aggiornare il carico dei bilanciatori in modo dinamico man mano che appaiono gli endpoint GKE verso il basso.

Il seguente diagramma illustra questi concetti per le applicazioni interne ed esterne traffico:

In questo diagramma, il bilanciatore del carico delle applicazioni esterno è in ascolto per il 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 di eseguirne il bilanciamento del carico sui backend in un data center di Google.

Il bilanciatore del carico delle applicazioni interno è in ascolto all'interno dell'ambito della tua rete VPC, consentendo di effettuare comunicazioni private all'interno. Queste proprietà del bilanciatore del carico le rendono adatte a diverse 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 GKE Ingress e un controller GKE Service integrati che eseguono il deployment di bilanciatori del carico per conto degli utenti GKE. È la stessa infrastruttura di bilanciamento del carico delle VM, tranne che il suo ciclo di vita è completamente automatizzato e controllato da GKE. Lo strumento GKE i controller di rete forniscono il bilanciamento del carico IP dei pod nativo del container interfacce "guidate" e di livello superiore conformi all'API Ingress and Service standard.

Il seguente diagramma illustra come la rete GKE automatizzano la creazione dei bilanciatori del carico:

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

Il controller continua a gestire il bilanciatore del carico e i backend in base cambiamenti ambientali e di traffico. Per questo motivo, i carichi di lavoro GKE diventa un bilanciatore del carico dinamico e autosufficiente con un 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 fondamentali per considerare. Con la suite di risorse Ingress e servizi di GKE di controllo, puoi esporre le applicazioni tenendo a mente ognuno di questi fattori.

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

Per un confronto dettagliato delle funzionalità di Ingress, consulta 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 del frontend 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 dalla rete del cluster, il che consente loro di utilizzare il bilanciamento del carico ClusterIP nativo di Kubernetes.

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

I client potrebbero anche essere esterni e che accedono alla tua applicazione dall'intera tramite la rete internet pubblica. Ogni tipo di rete determina un diverso bilanciamento del carico una topologia.

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

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

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

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

Protocollo

Un protocollo è il linguaggio utilizzato dai client per comunicare con l'applicazione. Le applicazioni vocali, di gioco e a bassa latenza utilizzano comunemente TCP o UDP direttamente, richiedendo bilanciatori del carico con controllo granulare a livello 4. Altre applicazioni comunica HTTP, HTTPS, gRPC o HTTP2 e richiedono bilanciatori del carico con che supportano questi protocolli. I requisiti di protocollo definiscono ulteriormente quali tipi di di esposizione alle applicazioni sono i più adatti.

In GKE puoi configurare bilanciatori del carico di livello 4, che indirizzano il traffico in base alle informazioni di rete come porta e protocollo, e bilanciatori del carico di livello 7, che sono a conoscenza delle informazioni dell'applicazione come le sessioni client. Ogni diverso bilanciatore del carico viene fornito con un supporto di protocollo specifico, come mostrato in tabella seguente:

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

Regionalità dell'applicazione

La regione dell'applicazione si riferisce al grado di distribuzione dell'applicazione in più di una regione o di un cluster GKE. L'hosting di una singola istanza di un'applicazione ha requisiti diversi rispetto all'hosting di istanze redundanti di un'applicazione su due cluster GKE indipendenti. L'hosting di un un'applicazione distribuita geograficamente in cinque cluster GKE carichi di lavoro più vicini all'utente finale per una latenza minore richiede consapevolezza multi-cluster e multiregionale per il bilanciatore del carico.

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

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

  • Ambito frontend: questo ambito indica se un indirizzo IP del bilanciatore del carico ascolta in un'unica regione o in più regioni. Tutti i bilanciatori del carico esterni ascoltano su internet, che è intrinsecamente multi-regione, ma alcuni bilanciatori del carico interni ascoltano solo all'interno di una singola regione.

La tabella seguente illustra 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
Ingresso interno
Ingresso esterno
Cluster multipli Ingress multi-cluster
Ambito del frontend Soluzioni disponibili
Regionale Servizio ClusterIP
Ingress interno
Globale Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
Servizio LoadBalancer esterno
In entrata esterna
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 sostituzioni o complementi validi per i bilanciatori del carico GKE.

Ingress nel cluster

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

I controller Ingress all'interno del cluster sono in genere conformi alla specifica Kubernetes Ingress e offrono funzionalità e facilità d'uso diverse. L'open source soluzioni richiedono una gestione più accurata e un livello più alto competenze tecniche, ma potrebbero soddisfare le tue esigenze se forniscono funzionalità specifiche richieste dalle tue applicazioni. Esiste anche un vasto ecosistema di soluzioni Ingress enterprise basate sulla community open source che offrono funzionalità avanzate e assistenza aziendale.

Gruppi di endpoint di rete (NEG) autonomi

I controller di Ingress e Service di GKE forniscono metodi automatici, dichiarativi e nativi di Kubernetes per il deployment del bilanciamento del carico cloud. 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 i backend di container e VM.

I NEG autonomi offrono questa possibilità aggiornando dinamicamente gli IP di backend dei pod per un NEG, ma consentono di eseguire il deployment del frontend del bilanciatore del carico manualmente. In questo modo viene fornito un controllo diretto e massimo del bilanciatore di carico, mantenendo al contempo i backend dinamici controllati dal cluster GKE.

Mesh di servizi

Le 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 le regioni e anche tra i container e le VM. In questo modo, la linea tra il bilanciamento del carico interno (traffico est-ovest) e l'esposizione dell'applicazione (traffico nord-sud) diventa meno netta. Con la flessibilità e la portata di un servizio moderno con i piani di controllo della rete mesh, è più probabile che mai nello stesso ambito del mesh di servizi. La versione precedente di GKE Le soluzioni Ingress e di servizio di solito distribuiscono bilanciatori del carico proxy medio per che non hanno proxy collaterali propri. Tuttavia, se un cliente server si trovano nello stesso mesh, l'esposizione dell'applicazione può essere gestita utilizzando mesh anziché il bilanciamento del carico del proxy medio.

Passaggi successivi