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 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 per quanto riguarda il modo in cui possono e devono comunicare. Può essere semplice come esporre l'applicazione nel cluster Kubernetes per il consumo da parte dei pod oppure complicato come instradare il traffico verso l'applicazione da client internet di tutto il mondo. GKE offre molti modi per esporre le applicazioni come servizi adatti ai tuoi casi d'uso specifici.

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 la modalità di elaborazione e instradamento del traffico. Puoi instradare il traffico verso i servizi in base a parametri come protocolli, intestazioni HTTP e percorsi HTTP. A seconda del bilanciatore del carico che utilizzi, il traffico potrebbe essere bilanciato per offrire 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 di applicazioni e dall'integrazione Service Discovery di backend. GKE utilizza l'integrazione Service Discovery per aggiornare dinamicamente i backend dei bilanciatori 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 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 rete VPC, consentendo di effettuare comunicazioni private internamente. Queste proprietà li rendono adatti 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 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. I controller di rete GKE forniscono il bilanciamento del carico IP dei pod nativo del container utilizzando interfacce di livello superiore opinative conformi agli standard delle API Ingress e Service.

Il seguente diagramma illustra in che modo i controller di 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 alle modifiche dell'ambiente 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 la tua applicazione in GKE, la rete del client, il protocollo e la regionalità dell'applicazione sono i fattori fondamentali 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 coprano tutti gli aspetti della rete di applicazioni, esaminare 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 tipi diversi di applicazioni, tutti con requisiti unici, quindi è probabile che ne utilizzerai più di uno in un determinato 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 su dove deve essere in ascolto il frontend del bilanciatore del carico. 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 consentirà loro di utilizzare il bilanciamento del carico ClusterIP nativo di Kubernetes.

I client possono anche essere client di rete interna che accedono alla tua applicazione dall'interno del Virtual Private Cloud (VPC) o da una rete on-premise tramite un Cloud Interconnect.

I client possono anche essere esterni e accedere alla tua applicazione tramite la rete internet pubblica. Ogni tipo di rete richiede una diversa topia 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 direttamente accessibile da internet. Esterno si riferisce alla 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 le 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
Ingresso esterno
Ingresso multi cluster

1 I cluster GKE che utilizzano il flag --no-enable-private-nodes possono avere nodi con indirizzi IP pubblici e privati, 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 supportano HTTP, HTTPS, gRPC o HTTP2 e richiedono bilanciatori del carico con il supporto esplicito di questi protocolli. I requisiti del protocollo definiscono ulteriormente i tipi di metodi di esposizione dell'applicazione 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 bilanciatore del carico è dotato di un supporto specifico per i protocolli, come indicato nella 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 regionalità dell'applicazione si riferisce al grado in cui l'applicazione è distribuita 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 redundanti di un'applicazione su due cluster GKE indipendenti. L'hosting di un'applicazione distribuita geograficamente su cinque cluster GKE per posizionare i carichi di lavoro più vicino all'utente finale per una latenza inferiore richiede ancora più consapevolezza multi-cluster e multi-regionale per il bilanciatore del carico.

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

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

  • 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 seguente tabella suddivide le soluzioni di bilanciamento del carico di GKE in queste due dimensioni.

Ambito 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
Ingresso interno
Globale Servizio ClusterIP
Servizio NodePort
Servizio LoadBalancer interno
Servizio LoadBalancer esterno
Ingresso esterno
Ingresso 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.

Ingresso all'interno del cluster

Ingress in cluster si riferisce ai controller Ingress software i cui proxy Ingress sono ospitati all'interno del cluster Kubernetes stesso. Questo è diverso dai controller Ingress di GKE, che ospitano e gestiscono la propria infrastruttura di bilanciamento del carico separatamente dal cluster Kubernetes. Queste soluzioni di terze parti vengono in genere implementate e gestite autonomamente dall'operatore del cluster. istio-ingressgateway e nginx-ingress sono due esempi di controller Ingress in-cluster open source 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. Le soluzioni open source probabilmente richiedono una gestione più attenta e un livello più elevato di competenza tecnica, ma potrebbero soddisfare le tue esigenze se forniscono funzionalità specifiche richieste dalle tue applicazioni. Esiste anche un vasto ecosistema di soluzioni Ingress per le aziende 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 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 i backend delle VM e dei contenitori.

Le NEG autonome offrono questa funzionalità 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 container e VM. In questo modo, la linea di demarcazione tra il bilanciamento del carico interno (traffico est-ovest) e l'esposizione delle applicazioni (traffico nord-sud) diventa meno netta. Con la flessibilità e la copertura dei piani di controllo dei service mesh moderni, è più probabile che il client e il server si trovino nello stesso ambito del mesh di servizi. Le soluzioni di Ingress e Service di GKE precedenti generalmente implementano bilanciatori del carico di proxy intermedi per i client che non dispongono di proxy sidecar propri. 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 del proxy intermedio.

Passaggi successivi