Multi Cluster Ingress è un controller ospitato sul cloud per i cluster Google Kubernetes Engine (GKE). È una Servizio ospitato da Google che supporta il deployment di risorse di bilanciamento del carico condivise in più cluster e regioni. Per eseguire il deployment di Ingress multi-cluster su più cluster, completa la procedura Configurazione di Ingress multi-cluster quindi vedi Deployment di Ingress in più cluster.
Per un confronto dettagliato tra Ingress multi-cluster (MCI), gateway multi-cluster (MCG) e bilanciatore del carico con gruppi di endpoint di rete autonomi (LB e standalone) NEG), consulta Scegliere l'API di bilanciamento del carico multi-cluster per GKE.
Networking multi-cluster
Molteplici fattori determinano le topologie multi-cluster, tra cui la vicinanza degli utenti per le app, l'alta disponibilità a livello di cluster e di regione, la separazione di sicurezza e organizzativa, la migrazione dei cluster e la localizzazione dei dati. Questi casi d'uso sono raramente isolati. Con l'aumento dei motivi per cui utilizzare più cluster, la necessità di una piattaforma multi-cluster formale e commercializzata diventa più urgente.
Ingress multi-cluster è progettato per soddisfare le esigenze di bilanciamento del carico degli ambienti multi-cluster e multi-regionali. Si tratta di un controller per il bilanciatore del carico HTTP(S) esterno per fornire l'ingresso per il traffico proveniente da internet su uno o più cluster.
Il supporto multi-cluster di Multi Cluster Ingress soddisfa molti casi d'uso, tra cui:
- Un unico IP virtuale (VIP) coerente per un'app, indipendentemente da dove si trova a livello globale.
- Disponibilità su più regioni e multi-cluster tramite controllo di integrità e traffico di failover.
- Instradamento basato su prossimità attraverso VIP Anycast pubblici per una bassa latenza del client.
- Migrazione trasparente del cluster per upgrade o ricostruzioni del cluster.
Quote predefinite
Ingress multi-cluster ha le seguenti quote predefinite:
- Per informazioni dettagliate sui limiti di membri per i parchi risorse, consulta le quote per la gestione del parco risorse. per il numero di membri supportati in un parco risorse.
- 100 risorse
MultiClusterIngress
e 100MultiClusterService
risorse per progetto. Puoi creare fino a 100MultiClusterIngress
e 100MultiClusterService
risorse in un cluster di configurazione per un numero qualsiasi di backend fino al cluster massimo per progetto.
Prezzi e prove
Per informazioni sui prezzi di Ingress multi-cluster, consulta Prezzi di Ingress multi-cluster.
Come funziona Ingress multi-cluster
Ingress multicluster si basa sull'architettura del bilanciatore del carico delle applicazioni esterno globale. La Il bilanciatore del carico delle applicazioni esterno globale è un bilanciatore del carico distribuito a livello globale con proxy implementato in più di 100 POP di Google in tutto il mondo. Questi proxy, chiamati Google Front End (GFE), si trovano sul perimetro della rete di Google, vicino ai client. Ingress multi-cluster crea bilanciatori del carico delle applicazioni esterni Livello Premium. Questi bilanciatori del carico utilizzare indirizzi IP esterni globali pubblicizzati tramite anycast. Le richieste vengono gestite dai GFE e dal cluster più vicino al client. Traffico internet va al PoP di Google più vicino e utilizza la rete backbone di Google per raggiungere cluster GKE. Questa configurazione di bilanciamento del carico genera diminuzione della latenza dal client al GFE. Puoi anche ridurre la latenza tra il servizio in cluster GKE e i GFE eseguendo i cluster GKE nelle regioni più vicine ai tuoi clienti.
La terminazione delle connessioni HTTP e HTTPS a livello perimetrale consente il carico di Google per decidere dove indirizzare il traffico determinando la disponibilità del backend prima che il traffico entri in un data center o in una regione. In questo modo il traffico in modo efficiente dal client al backend, mentre si considera integrità e capacità.
Ingress multi-cluster è un controller Ingress che programma i protocolli HTTP(S) esterni
bilanciatore del carico utilizzando gruppi di endpoint di rete (NEG).
Quando crei una risorsa MultiClusterIngress
, GKE esegue il deployment delle risorse bilanciatore del carico Compute Engine e configura i pod appropriati nei cluster come backend. I NEG vengono utilizzati per monitorare dinamicamente gli endpoint dei pod in modo che il bilanciatore del carico di Google abbia l'insieme corretto di backend funzionanti.
Quando esegui il deployment delle applicazioni nei vari cluster in GKE, Ingress multi-cluster garantisce che il bilanciatore del carico sia sincronizzato con gli eventi che si verificano nel cluster:
- Viene creato un deployment con le etichette corrispondenti corrette.
- Il processo di un pod si arresta in modo anomalo e non supera il controllo di integrità.
- Un cluster viene rimosso dal pool di backend.
Ingress multi-cluster aggiorna il bilanciatore del carico, mantenendolo coerente con dell'ambiente di lavoro e lo stato desiderato delle risorse Kubernetes.
Architettura di Ingress multi-cluster
Ingress multi-cluster utilizza un server API Kubernetes centralizzato per eseguire il deployment di Ingress
in più cluster. Questo server API centralizzato è chiamato cluster di configurazione. Qualsiasi
Il cluster GKE può fungere da cluster di configurazione. Il cluster di configurazione
utilizza due tipi di risorse personalizzate: MultiClusterIngress
e MultiClusterService
.
Eseguendo il deployment di queste risorse nel cluster di configurazione, il cluster Ingress multi-cluster
esegue il deployment di bilanciatori del carico in più cluster.
I seguenti concetti e componenti compongono Ingress multi-cluster:
Controller Ingress multi-cluster: si tratta di un piano di controllo distribuito a livello globale che viene eseguito come servizio esterno ai cluster. Ciò consente il ciclo di vita e le operazioni del controller cluster GKE.
Cluster di configurazione: si tratta di un cluster GKE scelto in esecuzione su Google Cloud in cui vengono di cui è stato eseguito il deployment delle risorse
MultiClusterIngress
eMultiClusterService
. Si tratta di un punto di controllo centralizzato per queste risorse multi-cluster. Queste risorse multi-cluster esistono e sono accessibili da un'unica API logica per mantenere la coerenza in tutti i cluster. Il controller Ingress controlla il cluster di configurazione e esegue le riconciliazioni per l'infrastruttura di bilanciamento del carico.Un parco risorse ti consente di raggruppare e normalizzare logicamente i cluster GKE, semplificando l'amministrazione dell'infrastruttura e consentendo l'utilizzo di funzionalità multi-cluster come Ingress multi-cluster. Per scoprire di più sui vantaggi dei parchi risorse e su come crearli, consulta la documentazione sulla gestione dei parchi risorse. Un cluster può essere membro di un solo parco risorse.
Cluster di membri: i cluster registrati in un parco risorse sono chiamati cluster membri. I cluster membri del parco risorse comprendono l'intero ambito dei backend di cui è a conoscenza Ingress multi-cluster. La Vista sulla gestione dei cluster Google Kubernetes Engine una console sicura per visualizzare lo stato di tutti i domini cluster.
Flusso di lavoro del deployment
I passaggi riportati di seguito illustrano un flusso di lavoro di alto livello per l'utilizzo di Multi Cluster Ingress su più cluster.
Registra i cluster GKE in un parco risorse nel progetto scelto.
Configurare un cluster GKE come cluster di configurazione centrale. Questo cluster può essere un piano di controllo dedicato o può eseguire altri carichi di lavoro.
Eseguire il deployment delle applicazioni nei cluster GKE dove necessario vengono eseguiti tutti i test delle unità.
Esegui il deployment di una o più risorse
MultiClusterService
nel cluster di configurazione con corrispondenze di etichette e cluster per selezionare cluster, spazio dei nomi e pod considerati backend per un determinato servizio. In questo modo vengono creati NEG in Compute Engine, che iniziano a registrare e gestire gli endpoint di servizio.Esegui il deployment di una risorsa
MultiClusterIngress
nel cluster di configurazione che fa riferimento a una o più risorseMultiClusterService
come backend per il bilanciatore del carico. Questa operazione esegue il deployment del bilanciatore del carico esterno di Compute Engine delle risorse ed espone gli endpoint in tutti i cluster tramite un singolo carico il VIP del bilanciatore del carico e del bilanciatore del carico.
Concetti di Ingress
Multi Cluster Ingress utilizza un server API Kubernetes centralizzato per eseguire il deployment di Ingress su più cluster. Le sezioni seguenti descrivono il modello di risorsa Ingress multi cluster, come eseguire il deployment di Ingress e i concetti importanti per la gestione di questo piano di controllo di rete ad alta disponibilità.
Risorse MultiClusterService
Un MultiClusterService
è una risorsa personalizzata utilizzata da Ingress multi-cluster
per rappresentare i servizi di condivisione tra i cluster. Un MultiClusterService
seleziona i pod, in modo simile alla risorsa Service, ma
MultiClusterService
può anche selezionare etichette e cluster. Il pool di cluster a cui si riferisce
Le selezioni di MultiClusterService
sono chiamate cluster membri. Tutti i
cluster registrati nel parco risorse sono cluster membri.
Un MultiClusterService
esiste solo nel cluster di configurazione e non instrada
nulla come un servizio ClusterIP, LoadBalancer o NodePort. Invece,
permette al controller Ingress multi-cluster di fare riferimento a una singola risorsa distribuita.
Il seguente manifest di esempio descrive un MultiClusterService
per un'applicazione denominata foo
:
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: foo
namespace: blue
spec:
template:
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
Questo manifest esegue il deployment di un servizio in tutti i cluster membri con il selettore app:
foo
. Se nel cluster esistono app: foo
pod, questi indirizzi IP vengono
aggiunti come backend per MultiClusterIngress
.
Il seguente mci-zone1-svc-j726y6p1lilewtu7
è un servizio derivato
generato in uno dei cluster di destinazione. Questo servizio crea un NEG che monitora gli endpoint dei pod per tutti i pod che corrispondono al selettore di etichette specificato in questo cluster. In ogni cluster di destinazione esisteranno un servizio e un NEG derivati per ogni
MultiClusterService
(a meno che non vengano utilizzati i selettori di cluster). Se non esistono pod corrispondenti
esistono in un cluster di destinazione, il servizio e il NEG saranno vuoti. Il valore derivato
I servizi sono gestiti completamente da MultiClusterService
e non da
direttamente gli utenti.
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
name: mci-zone1-svc-j726y6p1lilewtu7
namespace: blue
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
Alcune note sul servizio derivato:
- La sua funzione è quella di raggruppare logicamente gli endpoint come backend per Ingress multi-cluster.
- Gestisce il ciclo di vita del gruppo di istanze Elastic per un determinato cluster e un'applicazione.
- Viene creato come servizio headless. Tieni presente che solo i campi
Selector
ePorts
vengono trasferiti daMultiClusterService
al servizio derivato. - Il controller Ingress ne gestisce il ciclo di vita.
Risorsa MultiClusterIngress
Una risorsa MultiClusterIngress
si comporta in modo identico per molti aspetti
della risorsa principale Ingress. Entrambi hanno le stesse specifiche per la definizione di host,
la terminazione del protocollo e i backend.
Il seguente manifest descrive un MultiClusterIngress
che instrada il traffico a
i backend foo
e bar
, a seconda delle intestazioni dell'host HTTP:
apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
name: foobar-ingress
namespace: blue
spec:
template:
spec:
backend:
serviceName: default-backend
servicePort: 80
rules:
- host: foo.example.com
backend:
serviceName: foo
servicePort: 80
- host: bar.example.com
backend:
serviceName: bar
servicePort: 80
Questa risorsa MultiClusterIngress
associa il traffico all'indirizzo IP virtuale su
foo.example.com
e bar.example.com
inviandolo alle risorse MultiClusterService
denominate foo
e bar
. Questo MultiClusterIngress
ha un backend predefinito che corrisponde a tutto il resto del traffico e lo invia
nel backend MultiClusterService
.
Il seguente diagramma mostra come il traffico passa da una risorsa Ingress a un cluster:
Nel diagramma sono presenti due cluster, gke-us
e gke-eu
. Flussi di traffico
da foo.example.com
ai pod con l'etichetta app:foo
in entrambi
cluster. Da bar.example.com
, il traffico passa ai pod con l'etichetta
app:bar
in entrambi i cluster.
Risorse in entrata nei cluster
Il cluster di configurazione è l'unico che può avere MultiClusterIngress
e
MultiClusterService
risorse. Ogni cluster di destinazione con pod corrispondenti
anche i selettori di etichette MultiClusterService
hanno una funzione derivata
Servizio programmato per il cliente. Se un cluster non è selezionato esplicitamente da un
MultiClusterService
, non viene creato un servizio derivato corrispondente in quel cluster.
Identicità dello spazio dei nomi
L'uguaglianza dello spazio dei nomi è una proprietà dei cluster Kubernetes in cui uno spazio dei nomi si estende nei cluster ed è considerato lo stesso spazio dei nomi.
Nel seguente diagramma, lo spazio dei nomi blue
esiste nei cluster GKE gke-cfg
,
gke-eu
e gke-us
. L'identicità dello spazio dei nomi considera
lo spazio dei nomi blue
in modo che sia lo stesso in tutti i cluster. Ciò significa che un utente
ha gli stessi privilegi per le risorse nello spazio dei nomi blue
in ogni cluster.
L'identità dello spazio dei nomi significa anche che le risorse di servizio con lo stesso nome in più cluster nello spazio dei nomi blue
sono considerate come lo stesso servizio.
Il gateway tratta il servizio come un unico pool di endpoint in tutti e tre
cluster. Poiché le risorse Route e MultiClusterIngress
possono indirizzare solo ai servizi all'interno dello stesso spazio dei nomi, questo garantisce la multitenancy coerente della configurazione in tutti i cluster del parco risorse. I parchi risorse offrono un alto grado di
perché è possibile eseguire il deployment delle risorse o spostarle tra i cluster senza dover
modifiche alla configurazione. Il deployment nello stesso spazio dei nomi del parco risorse garantisce la coerenza tra i cluster.
Tieni presente i seguenti principi di progettazione per l'identità dello spazio dei nomi:
- Gli spazi dei nomi per scopi diversi non devono avere lo stesso nome tra cluster.
- Gli spazi dei nomi devono essere riservati in modo esplicito, allocando uno spazio dei nomi, o implicitamente, tramite criteri out-of-band, per i team e i cluster all'interno di un parco risorse.
- Gli spazi dei nomi per lo stesso scopo nei vari cluster devono avere lo stesso nome.
- L'autorizzazione dell'utente per gli spazi dei nomi tra i cluster deve essere strettamente controllati per impedire l'accesso non autorizzato.
- Non utilizzare lo spazio dei nomi predefinito o spazi dei nomi generici come "prod" o "dev" per il normale deployment dell'applicazione. È troppo facile per gli utenti eseguire il deployment delle risorse nello spazio dei nomi predefinito per errore e violare i principi di segmentazione degli spazi dei nomi.
- È necessario creare lo stesso spazio dei nomi tra i cluster ovunque o un gruppo di utenti deve eseguire il deployment delle risorse.
Progettazione del cluster di configurazione
Il cluster di configurazione Ingress multi-cluster è un singolo cluster GKE che
ospita le risorse MultiClusterIngress
e MultiClusterService
e agisce come
l'unico punto di controllo per Ingress
nel parco risorse di cluster GKE di destinazione. Scegli il cluster di configurazione quando attivi Ingress multi-cluster. Puoi scegliere qualsiasi cluster GKE come cluster di configurazione e modificarlo in qualsiasi momento.
Disponibilità del cluster di configurazione
Poiché il cluster di configurazione è un unico punto di controllo, le risorse Multi Cluster Ingress
non possono essere create o aggiornate se l'API del cluster di configurazione non è disponibile. Carica
I bilanciatori e il traffico gestito non saranno interessati da una configurazione
interruzione del cluster, ma cambia in MultiClusterIngress
e MultiClusterService
risorse non verranno riconciliate dal controller finché non saranno nuovamente disponibili.
Considera i seguenti principi di progettazione per i cluster di configurazione:
- Il cluster di configurazione deve essere scelto in modo che sia altamente disponibile. I cluster regionali sono preferiti rispetto ai cluster zonali.
- Per abilitare Ingress multi-cluster, non è necessario che il cluster di configurazione
un cluster dedicato. Il cluster di configurazione può ospitare carichi di lavoro amministrativi o anche di applicazioni, ma devi assicurarti che le applicazioni ospitate non influiscano sulla disponibilità del server API del cluster di configurazione. Il cluster di configurazione può essere un cluster di destinazione che ospita i backend per le risorse
MultiClusterService
, anche se, se sono necessarie precauzioni aggiuntive, il cluster di configurazione può anche essere escluso come backend tramite la selezione del cluster. - I cluster di configurazione devono avere tutti gli spazi dei nomi utilizzati dalla destinazione
backend dei cluster. Una risorsa
MultiClusterService
può fare riferimento solo a pod in lo stesso spazio dei nomi nei cluster, in modo che lo spazio dei nomi sia presente di configurazione del deployment. - Gli utenti che eseguono il deployment di Ingress su più cluster devono avere accesso al cluster di configurazione per eseguire il deployment delle risorse
MultiClusterIngress
eMultiClusterService
. Tuttavia, gli utenti devono avere accesso solo agli spazi dei nomi di cui l'autorizzazione all'utilizzo.
Selezione e migrazione del cluster di configurazione
Devi scegliere il cluster di configurazione quando attivi Ingress multi-cluster. Qualsiasi cluster membro di un parco risorse può essere selezionato come cluster di configurazione. Puoi aggiornare il cluster
config in qualsiasi momento, ma devi assicurarti che non causi interruzione. Il controller Ingress riconcilia le risorse esistenti nel cluster di configurazione. Quando esegui la migrazione del cluster di configurazione dal cluster corrente a quello successivo, le risorse MultiClusterIngress
e MultiClusterService
devono essere identiche.
Se le risorse non sono identiche, i bilanciatori del carico Compute Engine
potrebbero essere aggiornati o eliminati dopo l'aggiornamento del cluster di configurazione.
Il seguente diagramma mostra come un sistema CI/CD centralizzato applichi sempre le risorse MultiClusterIngress
e MultiClusterService
al server API GKE per il cluster di configurazione (gke-us
) e un cluster di backup (gke-eu
) in modo che le risorse siano identiche nei due cluster. Puoi modificare il cluster di configurazione per emergenze o per i tempi di riposo pianificati in qualsiasi momento senza alcun impatto perché le risorse MultiClusterIngress
e MultiClusterService
sono identiche.
Selezione del cluster
Le risorse MultiClusterService
possono essere selezionate in più cluster. Per impostazione predefinita, il controller pianifica un servizio derivato su ogni cluster di destinazione. In caso contrario
Se vuoi un servizio derivato su ogni cluster di destinazione, puoi definire un elenco
cluster utilizzando il campo spec.clusters
nel manifest MultiClusterService
.
Ti consigliamo di definire un elenco di cluster se hai bisogno di:
- Isola il cluster di configurazione per impedire la selezione delle risorse
MultiClusterService
nel cluster di configurazione. - Controlla il traffico tra i cluster per la migrazione delle applicazioni.
- Instrada i backend dell'applicazione che esistono solo in un sottoinsieme di cluster.
- Utilizza un singolo indirizzo IP virtuale HTTP(S) per l'instradamento ai backend che si trovano su cluster diversi.
Devi assicurarti che i cluster membri all'interno della stessa flotta e della stessa regione abbiano nomi univoci per evitare collisioni dei nomi.
Per scoprire come configurare la selezione del cluster, consulta Configurazione di Ingress multi-cluster.
Il seguente file manifest descrive un MultiClusterService
che ha un clusters
che fa riferimento a europe-west1-c/gke-eu
e
asia-northeast1-a/gke-asia
:
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: foo
namespace: blue
spec:
template:
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
clusters:
- link: "europe-west1-c/gke-eu"
- link: "asia-northeast1-a/gke-asia-1"
Questo manifest specifica che i pod con le etichette corrispondenti nei cluster gke-asia
e gke-eu
possono essere inclusi come backend per MultiClusterIngress
.
Tutti gli altri cluster vengono esclusi anche se hanno pod con app: foo
dell'etichetta.
Il seguente diagramma mostra un esempio di configurazione di MultiClusterService
che utilizza il manifest precedente:
Nel diagramma sono presenti tre cluster: gke-eu
, gke-asia-1
e
gke-asia-2
. Il cluster gke-asia-2
non è incluso come backend, anche se
esistono pod con etichette corrispondenti, perché il cluster non è incluso
dell'elenco spec.clusters
del file manifest. Il cluster non riceve traffico per operazioni di manutenzione o di altro tipo.
Passaggi successivi
- Scopri come configurare Ingress multi-cluster.
- Scopri di più sul deployment di gateway multi-cluster.
- Informazioni su Deployment di Ingress multi-cluster.
- Implementa Ingress multi-cluster per il bilanciamento del carico esterno.