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 il gli aspetti del networking di servizi e le funzionalità della 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 utilizzate dai clienti. Nella sua forma più semplice, un servizio è un servizio 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 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 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 traffico al bilanciatore del carico. Questo è il una località di rete che ascolta il traffico. Dispone di una rete, regione specifica (o subnet all'interno della rete), uno o più IP nel rete, porte, protocolli specifici e certificati TLS presentati 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 indirizzare il traffico a In base ai servizi su 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 dei bilanciatori del carico sono definiti dal tipo di l'integrazione di endpoint, piattaforme applicative e Service Discovery 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, Bilanciatore del carico delle applicazioni esterno è in ascolto del traffico sulla rete internet pubblica attraverso centinaia di POP Google in tutto il mondo. Questo livello globale il frontend consente di terminare il traffico a livello perimetrale, vicino ai client prima di bilanciare il carico del traffico verso i backend in un data center Google.

Il bilanciatore del carico delle applicazioni interno è in ascolto nell'ambito della tua rete VPC, consentendo alle comunicazioni private posizionare internamente. 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 offre uno strumento Controller GKE Ingress e Controller di servizio GKE che eseguono il deployment dei bilanciatori del carico per conto degli utenti GKE. È uguale all'infrastruttura di bilanciamento del carico della VM, ad eccezione del 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 dell'infrastruttura o di un'app esegue il deployment manifest dichiarativo rispetto al proprio cluster GKE. In entrata e I controller di servizio rilevano le risorse di networking di GKE (ad esempio oggetti Ingress) ed eseguire il deployment del carico bilanciatori (oltre a indirizzi IP, regole firewall ecc.) 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 ciascuno 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 in entrata.

Rete client

Una rete client si riferisce alla rete da cui si trovano i client delle applicazioni che accede all'applicazione. Questo influisce sulla posizione del frontend del carico deve rimanere in ascolto. Ad esempio, i clienti potrebbero trovarsi nello stesso cluster GKE come applicazione. In questo caso, sarebbero accedendo alla tua applicazione dall'interno della rete del cluster, consentendo loro di utilizzare Kubernetes-native Bilanciamento del carico ClusterIP.

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 accessibile direttamente da internet. Per esterno si intende la rete internet pubblica. I servizi ClusterIP sono interni a in un singolo cluster GKE, perciò l'ambito sarà 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 ogni nodo GKE e per rendere i servizi NodePort accessibili internamente ed esternamente.

Protocollo

Un protocollo è la lingua parlata dai client all'applicazione. Voce, giochi e le applicazioni a bassa latenza in genere usano direttamente TCP o UDP, che richiedono bilanciatori del carico con controllo granulare al 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 delle applicazioni sono i più adatti.

In GKE puoi configurare i bilanciatori del carico di livello 4, routing del traffico in base a informazioni di rete quali porta e protocollo e livello 7 bilanciatori del carico, che sono a conoscenza delle informazioni sull'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 		Ingress interno
Ingress esterno
Ingress 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. Hosting singolo di un'applicazione ha requisiti diversi rispetto all'hosting di server ridondanti di istanze di un'applicazione in 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 regione 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 di frontend: questo ambito si riferisce all'eventuale ascolto da parte di un IP del bilanciatore del carico all'interno di una singola regione o in più regioni. Tutti i bilanciatori del carico esterni restano in ascolto internet, che è intrinsecamente multiregionale, ma alcuni bilanciatori del carico interni di ascolto 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
Traffico 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
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 alternative o complementari Bilanciatori del carico GKE.

Ingress nel cluster

Ingress nel cluster si riferisce ai controller Ingress software che hanno Proxy in entrata 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 generalmente implementate e gestite autonomamente dell'operatore di cluster. gateway-in entrata e nginx-ingress sono due esempi di controller Ingress in-cluster open source comunemente usati.

I controller Ingress nel cluster sono generalmente conformi all'API Kubernetes Ingress specifiche e fornire diverse capacità e facilità d'uso. 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 risorse aziendali Ingress soluzioni basate sulla 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 funzionalità metodi 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 con una gestione controllo sul bilanciatore del carico o bilanciamento del carico tra container e VM di backend.

Questo è fornito dai NEG autonomi aggiornando gli IP del backend del pod in modo dinamico per un NEG, ma consenti il frontend del bilanciatore del carico per il deployment manuale. Ciò fornisce il massimo controllo diretto del bilanciatore del carico, mantenendo il controllo dei backend dinamici dal cluster GKE.

Mesh di servizi

I mesh di servizi forniscono il bilanciamento del carico lato client attraverso un controllo centralizzato aereo. Cloud Service Mesh e Cloud Service Mesh consente di bilanciare il carico del traffico interno su GKE tra container e VM, in varie regioni. Questo sfoca linea tra il bilanciamento del carico interno (traffico est-ovest) e l'applicazione esposizione (traffico nord-sud). 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 delle applicazioni può essere gestita utilizzando mesh anziché il bilanciamento del carico del proxy medio.

Passaggi successivi