Multi Cluster Ingress è un controller ospitato su cloud per i cluster Google Kubernetes Engine (GKE). Si tratta di un servizio ospitato da Google che supporta il deployment di risorse di bilanciamento del carico condivise tra cluster e in tutte le aree geografiche. Per eseguire il deployment di traffico multi-cluster in più cluster, completa la procedura di configurazione di più cluster Ingress e consulta la pagina relativa al deployment di Ingress su più cluster.
Networking multi-cluster
Molti fattori determinano topologie multi-cluster, tra cui la vicinanza degli utenti per app, cluster e alta disponibilità a livello di area geografica, sicurezza e separazione organizzativa, migrazione dei cluster e località dei dati. Questi casi d'uso sono isolati raramente. Man mano che i motivi per più cluster crescono, la necessità di una piattaforma multi-cluster formale e prodotta diventa più urgente.
Ingress multi-cluster è progettato per soddisfare le esigenze di bilanciamento del carico degli ambienti multi-cluster. Si tratta di un controller per il bilanciatore del carico HTTP(S) esterno per fornire traffico in entrata da Internet attraverso uno o più cluster.
Il supporto multi-cluster multi-cluster è adatto a molti casi d'uso, tra cui:
- Un singolo IP virtuale (VIP) coerente e coerente per un'app, indipendentemente dal luogo di deployment globale dell'app.
- Disponibilità per più aree geografiche e multi-cluster mediante controllo di integrità e failover del traffico.
- Routing basato su prossimità tramite VIP anycast pubblici per una bassa latenza dei client.
- Migrazione trasparente dei cluster per gli upgrade o le ricostruzioni dei cluster.
Quote predefinite
Ingress multi cluster ha le seguenti quote predefinite:
- 15 cluster per progetto.
- 50 risorse
MultiClusterIngress
e 100 risorseMultiClusterService
per progetto. Puoi creare fino a 50 risorseMultiClusterIngress
e 100MultiClusterService
in un cluster di configurazione per un numero qualsiasi di cluster di backend fino al massimo per cluster di progetto.
Contatta il team dedicato al tuo account o gke-mci-feedback@google.com per aumentare le quote.
Prezzi e prove
Per informazioni sui prezzi di Ingress multi-cluster, vedi Prezzi di Ingress multi-cluster.
Come funziona l'Ingress multi-cluster
L'Ingress multi cluster si basa sull'architettura del bilanciatore del carico HTTP(S) esterno esterno. Il bilanciatore del carico HTTP(S) esterno globale è un bilanciatore del carico distribuito a livello globale con proxy di cui è stato eseguito il deployment in oltre 100 punti di presenza Google (PoP) in tutto il mondo. Questi proxy, chiamati Google Front End (GFE), si trovano ai margini della rete Google, vicini ai clienti. Il Ingress multi-cluster crea bilanciatori del carico HTTP(S) esterni nel livello Premium. Questi bilanciatori del carico utilizzano indirizzi IP esterni globali pubblicizzati tramite anycast. Le richieste sono gestite dai GFE e dal cluster più vicino al client. Il traffico Internet passa al punto di accesso Google PoP più vicino e utilizza la rete backbone di Google per accedere a un cluster GKE. Questa configurazione del bilanciamento del carico comporta una minore latenza dal client al GFE. Puoi anche ridurre la latenza tra la gestione dei cluster GKE e i GFE eseguendo i cluster GKE nelle aree geografiche più vicine ai tuoi clienti.
L'interruzione delle connessioni HTTP e HTTPS a livello perimetrale consente al bilanciatore del carico Google di decidere dove indirizzare il traffico determinando la disponibilità del backend prima che entri in un data center o in un'area geografica. Ciò consente al traffico del percorso più efficiente dal client al backend tenendo in considerazione i backend e l'integrità e la capacità.
Ingress multi cluster è un controller Ingress che programma il bilanciatore del carico HTTP(S) esterno usando i gruppi di endpoint di rete (NEG).
Quando crei una risorsa MultiClusterIngress
, GKE esegue il deployment delle risorse del bilanciatore del carico Compute Engine e configura i pod appropriati tra i cluster come backend. I NEG vengono utilizzati per monitorare gli endpoint
dei pod in modo dinamico, in modo che il bilanciatore del carico Google disponga del giusto set di backend
sani.
Durante il deployment di applicazioni su cluster in GKE, l'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.
- Un processo del pod muore e non supera il controllo di integrità.
- Un cluster viene rimosso dal pool di backend.
Il traffico di più cluster Ingress aggiorna il bilanciatore del carico, mantenendolo coerente con l'ambiente e lo stato desiderato delle risorse Kubernetes.
Architettura Ingress multi-cluster
Ingress multi cluster utilizza un server API Kubernetes centralizzato per eseguire il deployment di Ingress su più cluster. Questo server API centralizzato è denominato cluster di configurazione. Qualsiasi cluster GKE può fungere da cluster di configurazione. Il cluster di configurazione utilizza due tipi di risorse personalizzati: MultiClusterIngress
e MultiClusterService
.
Eseguendo il deployment di queste risorse sul cluster di configurazione, il controller Ingress multi-cluster esegue il deployment dei bilanciatori del carico in più cluster.
I seguenti concetti e componenti costituiscono l'Ingress multi-cluster:
Controller Ingress multi-cluster: è un piano di controllo distribuito a livello globale che viene eseguito come servizio al di fuori dei tuoi cluster. Ciò consente al ciclo di vita e alle operazioni del controller di essere indipendenti dai cluster GKE.
Cluster di configurazione: cluster di GKE scelto in esecuzione su Google Cloud in 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 una singola API logica per mantenere la coerenza in tutti i cluster. Il controller Ingress controlla il cluster di configurazione e riconcilia l'infrastruttura di bilanciamento del carico.Una flotta è un gruppo di cluster e altre risorse. Cluster registrati per criteri di condivisione del gruppo e domini di identità. Un cluster può essere membro di un solo gruppo.
Cluster di membri: i cluster registrati in un gruppo sono denominati cluster membri. I cluster dei membri del parco comprendono l'ambito completo dei backend di cui è a conoscenza l'Ingress multi-cluster. La visualizzazione della gestione dei cluster di Google Kubernetes Engine offre una console sicura per visualizzare lo stato di tutti i tuoi cluster registrati.
Flusso di lavoro per il deployment
I seguenti passaggi illustrano un flusso di lavoro di alto livello per l'utilizzo di Ingress multi-cluster in più cluster.
Registra i cluster GKE come cluster di appartenenza.
Configura un cluster GKE come cluster di configurazione centrale. Questo cluster può essere un piano di controllo dedicato o può eseguire altri carichi di lavoro.
Esegui il deployment delle applicazioni nei cluster GKE su cui devono essere eseguite.
Esegui il deployment di una o più risorse
MultiClusterService
nel cluster di configurazione con corrispondenze di etichette e cluster per selezionare cluster, spazi dei nomi e pod considerati backend per un determinato servizio. In questo modo, verranno creati i 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. Esegue il deployment delle risorse del bilanciatore del carico esterno di Compute Engine ed espone gli endpoint tra i cluster tramite un singolo VIP con bilanciatore del carico.
Concetti di Ingress
Ingress multi cluster utilizza un server API Kubernetes centralizzato per eseguire il deployment di Ingress su più cluster. Le seguenti sezioni descrivono il modello di risorse Ingress multi-cluster, come eseguire il deployment di Ingress e i concetti importanti per gestire questo piano di controllo di rete a disponibilità elevata.
Risorse MultiClusterService
Un MultiClusterService
è una risorsa personalizzata utilizzata da Multi Cluster Ingress per rappresentare i servizi di condivisione tra cluster. Una risorsa MultiClusterService
seleziona pod, come la risorsa Servizio, ma una risorsa MultiClusterService
può anche selezionare etichette e cluster. Il pool di cluster selezionato da
MultiClusterService
è denominato cluster membri. Tutti i cluster
registrati nel parco sono cluster di membri.
MultiClusterService
esiste solo nel cluster di configurazione e non esegue il routing
di elementi come un servizio ClusterIP, LoadBalancer o NodePort. Invece, consente al controller Multi Cluster Ingress 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 file manifest esegue il deployment di un servizio in tutti i cluster membri con il selettore app:
foo
. Se in questo cluster sono presenti app: foo
pod, questi indirizzi IP pod vengono
aggiunti come backend per i 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 del pod per tutti i pod che corrispondono al selettore di etichette specificato in questo cluster. Esiste un servizio derivato e un NEG in ogni cluster di destinazione per ogni elemento MultiClusterService
(a meno che non si utilizzino selettori di cluster). Se non esiste un pod corrispondente in un cluster di destinazione, il servizio e il NEG saranno vuoti. I servizi derivati sono gestiti completamente da MultiClusterService
e non sono gestiti direttamente dagli 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 è come un raggruppamento logico degli endpoint come backend per il traffico multi-cluster.
- Gestisce il ciclo di vita del NEG per un cluster e un'applicazione specifici.
- Viene creato come servizio headless. Tieni presente che solo i campi
Selector
ePorts
vengono trasferiti daMultiClusterService
al servizio derivato. - Il controller Ingress gestisce il proprio ciclo di vita.
Risorsa MultiClusterIngress
Una risorsa MultiClusterIngress
si comporta in modo identico per
più risorse rispetto alla risorsa Ingress principale. Entrambi hanno le stesse specifiche per la definizione di host, percorsi, terminazioni di protocollo e backend.
Il file manifest seguente descrive un MultiClusterIngress
che indirizza il traffico ai
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
inviando questo traffico alle
risorse MultiClusterService
denominate foo
e bar
. Questo MultiClusterIngress
ha un backend predefinito corrispondente a tutto il resto del traffico e lo invia al MultiClusterService
backend predefinito.
Il seguente diagramma mostra il flusso del traffico da una risorsa Ingress a un cluster:
Nel diagramma sono presenti due cluster, gke-eu
e gke-asia
. Il traffico passa da foo.example.com
ai pod con etichetta app:foo
in entrambi i cluster. Da bar.example.com
, il traffico passa ai pod con l'etichetta app:bar
in entrambi i cluster.
Risorse in entrata tra i cluster
Il cluster di configurazione è l'unico cluster che può avere risorse MultiClusterIngress
e
MultiClusterService
. A ogni cluster di destinazione che contiene pod che corrispondono
ai selettori etichetta MultiClusterService
è programmato anche un
servizio derivato corrispondente. Se un cluster non è selezionato esplicitamente da un
MultiClusterService
, non viene creato un servizio derivato corrispondente in quel cluster.
Donazione dello spazio dei nomi
Lo stesso spazio dei nomi è una proprietà dei cluster Kubernetes in cui uno spazio dei nomi si estende tra cluster ed è considerato lo stesso spazio dei nomi. Ad esempio, se
lo spazio dei nomi blue
esiste in più cluster GKE, lo stesso
spazio dei nomi considera lo spazio dei nomi blue
uguale su tutti i cluster. Ciò
significa che un determinato utente ha gli stessi privilegi per le risorse nello spazio dei nomi blue
in ogni cluster. L'uniformità 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 lo stesso servizio.
Il seguente diagramma mostra l'uniformità dello spazio dei nomi:
Nel diagramma, ogni cluster ha un servizio store
nello spazio dei nomi store
. Il gateway considera il servizio come un singolo pool di endpoint in tutti e tre i cluster. Poiché le route e le risorse MultiClusterIngress
possono essere instradate solo a servizi all'interno dello stesso spazio dei nomi, questo fornisce un'architettura multi-tenancy coerente per la configurazione tra tutti i cluster. I gruppi offrono un elevato livello di portabilità, poiché il deployment delle risorse può essere eseguito o spostato tra i cluster senza alcuna modifica alla configurazione. Il deployment nello stesso spazio dei nomi del parco dispositivi garantisce coerenza tra i cluster.
Considera i seguenti principi di progettazione per lo stesso spazio dei nomi:
- Gli spazi dei nomi per scopi diversi non devono avere lo stesso nome nei cluster.
- Gli spazi dei nomi devono essere riservati in modo esplicito, allocando uno spazio dei nomi o implicitamente, tramite criteri fuori banda, a team e cluster all'interno di un parco dispositivi.
- Gli spazi dei nomi per lo stesso scopo in tutti i cluster devono condividere lo stesso nome.
- L'autorizzazione dell'utente per gli spazi dei nomi nei cluster deve essere rigorosamente controllata per evitare accessi non autorizzati.
- Non devi utilizzare lo spazio dei nomi predefinito o spazi dei nomi generici come "prod" o "dev" per il normale deployment delle applicazioni. È troppo facile per gli utenti eseguire il deployment accidentale delle risorse nello spazio dei nomi predefinito e violare i principi di segmentazione degli spazi dei nomi.
- Lo stesso spazio dei nomi deve essere creato in tutti i cluster in cui un determinato team o 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 da singolo punto di controllo per l'Ingress sul parco dei cluster GKE di destinazione. Puoi scegliere il cluster di configurazione quando attivi l'Ingress multi cluster. Puoi scegliere qualsiasi cluster GKE come cluster di configurazione e modificarlo in qualsiasi momento.
Disponibilità cluster di configurazione
Poiché il cluster di configurazione è un singolo punto di controllo, non è possibile creare o aggiornare le risorse Ingress multi-cluster se l'API Config Cluster non è disponibile. I bilanciatori del carico e il traffico pubblicato non saranno interessati da un'interruzione del cluster di configurazione, ma le modifiche alle risorse MultiClusterIngress
e MultiClusterService
non verranno riconciliate dal controller finché non saranno nuovamente disponibili.
Considera i seguenti principi di progettazione per i cluster di configurazione:
- È necessario scegliere il cluster di configurazione in modo che sia a disponibilità elevata. I cluster a livello di area geografica hanno la priorità rispetto ai cluster a livello di zona.
- Per abilitare Ingress in cluster multiplo, non è necessario che il cluster di configurazione sia un cluster dedicato. Il cluster di configurazione può ospitare carichi di lavoro amministrativi o anche
delle applicazioni, ma è necessario assicurarsi 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 backend per le risorse
MultiClusterService
, anche se sono necessarie ulteriori precauzioni. 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 dai backend del cluster di destinazione. Una risorsa
MultiClusterService
può fare riferimento a pod nello stesso spazio dei nomi tra cluster, in modo che quest'ultimo debba essere presente nel cluster di configurazione. - 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 per i quali dispongono dell'autorizzazione all'uso.
Selezione e migrazione del cluster di configurazione
Devi scegliere il cluster di configurazione quando attivi Ingress multi-cluster. Puoi selezionare qualsiasi cluster membro di un gruppo come cluster di configurazione. Puoi aggiornare il cluster di configurazione in qualsiasi momento, ma assicurati che non causi interruzioni. Il controller Ingress riconciliarà le risorse presenti nel cluster di configurazione. Quando esegui la migrazione del cluster di configurazione da quello attuale a quello successivo, le risorse MultiClusterIngress
e MultiClusterService
devono essere identiche.
Se le risorse non sono identiche, dopo il aggiornamento del cluster di configurazione potrebbero essere aggiornati o distrutti i bilanciatori del carico Compute Engine.
Il seguente diagramma mostra in che modo un sistema CI/CD centralizzato applica le risorse
MultiClusterIngress
e MultiClusterService
al server dell'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 le emergenze o il tempo di inattività pianificato in qualsiasi momento senza alcun impatto perché le risorse MultiClusterIngress
e MultiClusterService
sono identiche.
Selezione del cluster
MultiClusterService
risorse possono essere selezionate su più cluster. Per impostazione predefinita, il controller pianifica un servizio derivato su ogni cluster di destinazione e ignora tutti gli altri cluster di destinazione.
Per informazioni su come configurare la selezione del cluster, vedi Configurazione di Ingress multi-cluster.
Potrebbe essere necessario applicare regole di traffico in entrata a cluster specifici se devi:
- Isola il cluster di configurazione per evitare che
MultiClusterService
risorse selezioni in tutto il cluster di configurazione. - Controlla il traffico tra i cluster per la migrazione delle applicazioni.
- Instrada ai backend delle applicazioni che esistono solo in un sottoinsieme di cluster.
- Utilizza un singolo indirizzo IP virtuale HTTP(S) per il routing a backend su diversi cluster.
Puoi definire un elenco di cluster in cui il controller deve pianificare i servizi utilizzando il campo spec.clusters
nel file manifest MultiClusterService
.
I cluster fanno riferimento esplicito a <region | zone>/<name>
. Devi assicurarti che i cluster dei membri all'interno dello stesso gruppo e la stessa area geografica abbiano nomi univoci per evitare conflitti di denominazione.
Il seguente file manifest descrive un campo MultiClusterService
con un campo 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 file manifest specifica che i pod con le etichette corrispondenti nei cluster gke-asia
e gke-eu
possono essere inclusi come backend per l'elemento MultiClusterIngress
.
Tutti gli altri cluster sono esclusi anche se hanno pod con l'etichetta app: foo
.
Il seguente diagramma mostra una configurazione MultiClusterService
di esempio usando
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
sono presenti pod con etichette corrispondenti, perché non è incluso
nell'elenco manifest spec.clusters
. Il cluster non riceve traffico per la manutenzione o altre operazioni.
Passaggi successivi
- Scopri come configurare Ingress multi-cluster.
- Informazioni sul deployment di gateway multi-cluster.
- Scopri di più sul deployment di Ingress multi-cluster.