Questa pagina descrive come eseguire il deployment dei servizi in Google Kubernetes Engine (GKE). Utilizza questa pagina come guida per comprendere meglio le sfaccettature del networking di servizio e le funzionalità di rete di servizio esistenti in GKE.
Panoramica del networking di servizi
Il networking dei 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.
Client e applicazioni hanno esigenze diverse in termini di modalità di comunicazione. Può essere semplice come esporre l'applicazione nel cluster Kubernetes per il consumo dei pod o complicato come instradare il traffico verso l'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 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. Questa è la posizione di rete in ascolto del traffico. Ha 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 come elaborare e instradare il 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, 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 applicativa e dall'integrazione Service Discovery di backend. GKE utilizza l'integrazione 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 attesa di traffico su internet pubblico attraverso 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 bilanciare il carico del traffico sui backend in un data center Google.
Il bilanciatore del carico delle applicazioni interno è in ascolto nell'ambito della tua rete VPC, consentendo comunicazioni private internamente. Queste proprietà del bilanciatore del carico lo rendono adatto 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 GKE Ingress e un controller del servizio GKE integrati, 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 forniscono il bilanciamento del carico degli indirizzi IP dei pod nativi dei 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 proprio 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 di 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, i fattori principali da considerare sono la rete client, il protocollo e la regionalità dell'applicazione. 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 ogni aspetto 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, tutti con requisiti unici, quindi è probabile che ne utilizzerai più di uno in un determinato cluster.
Per un confronto dettagliato delle funzionalità di Ingress, vedi Configurazione Ingress.
Rete client
Una rete client si riferisce alla rete da cui i client dell'applicazione accedono all'applicazione. Ciò influisce sulla posizione in cui 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, accedono all'applicazione dall'interno della 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 alla tua applicazione da Virtual Private Cloud (VPC) o da una rete on-premise tramite Cloud Interconnect.
I client potrebbero anche essere esterni e accedere alla tua applicazione da internet pubblico. 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 direttamente accessibile da internet. Esterno si riferisce a internet pubblico. I servizi ClusterIP sono interni a un singolo cluster GKE, pertanto sono limitati 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 di bilanciamento del carico interno Ingress interno |
| Esterno |
Servizio NodePort1
Servizio di bilanciamento del carico esterno Ingress esterno Ingress multi-cluster |
1 I cluster GKE che utilizzano il flag --no-enable-private-nodes
possono avere nodi con indirizzi IP pubblici e privati e
quindi i servizi NodePort possono essere accessibili internamente ed esternamente.
Protocollo
Un protocollo è il linguaggio con cui i client comunicano con l'applicazione. Le applicazioni vocali, di gioco e a bassa latenza utilizzano comunemente TCP o UDP direttamente, richiedendo bilanciatori del carico con un controllo granulare a livello 4. Altre applicazioni utilizzano 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 bilanciatori del carico di livello 4, che instradano il traffico in base alle informazioni di rete come porta e protocollo, e bilanciatori del carico di livello 7, che conoscono le informazioni sulle applicazioni come le sessioni client. Ogni bilanciatore del carico diverso è dotato di un supporto specifico per i protocolli, come mostrato nella tabella seguente:
| Base | Protocolli | Soluzioni disponibili |
|---|---|---|
| L4 | TCP UDP |
Servizio ClusterIP
Servizio NodePort Servizio di bilanciamento del carico interno Servizio di bilanciamento del carico esterno |
| L7 |
HTTP
HTTPS HTTP2 |
Ingress interno
Ingress esterno Ingress multi-cluster |
Area geografica dell'applicazione
La regionalità dell'applicazione si riferisce al grado di distribuzione dell'applicazione in più di una regione o un 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 su cinque cluster GKE per posizionare i carichi di lavoro più vicino all'utente finale per una latenza inferiore richiede una consapevolezza ancora maggiore di più cluster e più regioni 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 alla possibilità di un bilanciatore del carico di inviare traffico ai backend in più cluster GKE. Ingress multi-cluster è in grado di esporre un singolo indirizzo IP virtuale che indirizza il traffico ai pod di cluster e regioni diversi.
Ambito frontend: questo ambito si riferisce al fatto che un IP del bilanciatore del carico è in ascolto all'interno di una singola regione o in più regioni. Tutti i bilanciatori del carico esterni sono in ascolto su internet, che è intrinsecamente multiregionale, ma alcuni bilanciatori del carico interni sono in ascolto solo all'interno di una singola regione.
La seguente tabella 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 di bilanciamento del carico interno Servizio di bilanciamento del carico 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 di bilanciamento del carico interno Servizio di bilanciamento del carico esterno Ingress esterno Ingress 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 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 è 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 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 e di uso comune.
I controller Ingress in-cluster in genere sono conformi alla specifica Ingress di Kubernetes e offrono funzionalità e facilità d'uso variabili. Le soluzioni open source probabilmente richiedono una gestione più attenta 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 aziendali create intorno alla community open source che forniscono funzionalità avanzate e assistenza aziendale.
Gruppi di endpoint di rete (NEG) autonomi
I controller Ingress e Service di 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 per avere un controllo diretto e più granulare sul bilanciatore del carico o per bilanciare il carico tra i backend di container e VM.
I NEG standalone forniscono questa funzionalità aggiornando dinamicamente gli IP di backend dei pod per un NEG, ma consentono 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 service mesh 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, il confine tra il bilanciamento del carico interno (traffico est-ovest) e l'esposizione delle applicazioni (traffico nord-sud) diventa meno netto. Grazie alla flessibilità e alla portata dei moderni piani di controllo service mesh, è più probabile che mai che sia il client che il server si trovino nello stesso ambito mesh di servizi. Le soluzioni GKE Ingress e Service precedenti in genere eseguono il deployment di bilanciatori del carico proxy intermedi per i client che non hanno i propri proxy sidecar. Tuttavia, se un client e un server si trovano nella stessa mesh, l'esposizione dell'applicazione può essere gestita utilizzando la mesh anziché il bilanciamento del carico del proxy intermedio.
Passaggi successivi
- Scopri di più sulle funzionalità di Ingress.
- Scopri di più sul traffico in entrata esterno.
- Scopri di più sul traffico interno in entrata.
- Utilizza servizi LoadBalancer esterni.
- Utilizza i servizi LoadBalancer interni.