Ingress multi-cluster

Ingress multi-cluster è un controller ospitato nel cloud di Google Kubernetes Engine (GKE). È un 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 autonomi) NEG), consulta Scegliere l'API di bilanciamento del carico multi-cluster per GKE.

Networking multi-cluster

Le topologie multi-cluster sono generate da molti fattori, inclusa la vicinanza dell'utente per app, cluster e regione ad alta disponibilità, sicurezza e separazione dei cluster, migrazione dei cluster e località dei dati. Questi casi d'uso sono raramente isolati. Man mano che aumentano le ragioni alla base di più cluster, è necessario una piattaforma multi-cluster formale e prodottizzata diventa più urgente.

Ingress multi-cluster è progettato per soddisfare le esigenze di bilanciamento del carico di ambienti multi-cluster, in ambienti multiregionali. È un controller per i protocolli HTTP(S) esterni che fornisce un bilanciatore del carico in entrata per il traffico proveniente da internet o più cluster.

Il supporto multi-cluster di Ingress multi-cluster 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 dei cluster per upgrade o rigenerazioni dei cluster.

Quote predefinite

Ingress multi-cluster ha le seguenti quote predefinite:

  • Per maggiori dettagli sui limiti per i membri per i parchi risorse, vedi Quote di gestione del parco risorse. per conoscere il numero di membri supportati in un parco risorse.
  • 100 risorse MultiClusterIngress e 100 MultiClusterService risorse per progetto. Puoi creare fino a 100 MultiClusterIngress e 100 MultiClusterService risorse in un cluster di configurazione per un numero qualsiasi di backend fino al cluster massimo per progetto.

Prezzi e prove

Per saperne di più sui prezzi di Ingress multi-cluster, consulta Prezzi di Ingress multi-cluster.

Come funziona Ingress multi-cluster

Ingress multi-cluster 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 chiamati proxy, Google Front End (GFE), si trovano ai margini della rete Google, vicini 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 sono gestito 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 le pubblicazioni Cluster GKE e GFE eseguendo i tuoi 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 del bilanciatore del carico Compute Engine e configura Pod nei cluster come backend. I NEG vengono utilizzati per monitorare il pod endpoint in modo dinamico, in modo che il bilanciatore del carico di Google abbia il giusto insieme di di backend.

Flusso di traffico Ingress multi-cluster

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 muore e non supera il controllo di integrità.
  • Un cluster viene rimosso dal pool dei backend.

Ingress multi-cluster aggiorna il bilanciatore del carico, mantenendolo coerente con dell'ambiente di lavoro 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 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 personalizzati: 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: è un controller Ingress multi-cluster distribuito a livello globale di controllo che viene eseguito come servizio al di fuori dei tuoi cluster. Ciò consente il ciclo di vita e le operazioni del controller cluster GKE.

  • Cluster di configurazione: è un cluster GKE scelto in esecuzione su in Google Cloud, dove MultiClusterIngress e MultiClusterService il deployment delle risorse. Si tratta di un punto di controllo centralizzato e multi-cluster. Queste risorse multi-cluster esistono accessibile da un'unica API logica per mantenere la coerenza 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'uso di funzionalità multi-cluster come Ingress multi-cluster. Per saperne di più sui vantaggi dei parchi risorse e su come crearli, consulta la documentazione sulla gestione del parco 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 dei membri nel parco risorse comprendono l'ambito completo dei backend che di Ingress multi-cluster. La Vista sulla gestione dei cluster Google Kubernetes Engine una console sicura per visualizzare lo stato di tutti i domini cluster.

Arco Ingress multi-cluster

Flusso di lavoro del deployment

I passaggi seguenti illustrano un flusso di lavoro di alto livello per l'utilizzo di Ingress multi-cluster in più cluster.

  1. Registra i cluster GKE in un parco risorse nel progetto scelto.

  2. Configurare un cluster GKE come cluster di configurazione centrale. Questo cluster può essere un piano di controllo dedicato oppure può eseguire altri carichi di lavoro.

  3. Eseguire il deployment delle applicazioni nei cluster GKE dove necessario vengono eseguiti tutti i test delle unità.

  4. Esegui il deployment di una o più risorse MultiClusterService nel cluster di configurazione con corrispondenze tra etichetta e cluster per selezionare cluster, spazio dei nomi e pod considerati backend per un determinato servizio. Questo crea NEG Compute Engine, che inizia a registrare e gestire gli endpoint dei servizi.

  5. Esegui il deployment di una risorsa MultiClusterIngress nel cluster di configurazione che fa riferimento a una o più risorse MultiClusterService come backend per con il bilanciatore del carico di rete passthrough esterno regionale. 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

Ingress multi-cluster utilizza un server API Kubernetes centralizzato per il deployment di Ingress in più cluster. Le seguenti sezioni descrivono il traffico Ingress multi-cluster di risorse, come eseguire il deployment di Ingress e concetti importanti per la gestione un piano di controllo di rete ad alta disponibilità.

Risorse MultiClusterService

MultiClusterService è una risorsa personalizzata utilizzata da Ingress multi-cluster per rappresentare i servizi di condivisione tra i cluster. 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 denominate cluster membri. Tutte le i cluster registrati nel parco risorse sono cluster membri.

Un MultiClusterService esiste solo nel cluster di configurazione e non esegue il routing come un servizio ClusterIP, LoadBalancer o NodePort. Invece, permette al controller Ingress multi-cluster di fare riferimento a una singola risorsa distribuita.

Il seguente file manifest di esempio descrive un MultiClusterService per un dell'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 membro 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 generate in uno dei cluster di destinazione. Questo servizio crea un NEG che monitora Endpoint dei pod per tutti i pod che corrispondono al selettore di etichette specificato in questo in un cluster Kubernetes. Esisteranno un servizio e un NEG derivati in ogni cluster di destinazione per ogni MultiClusterService (a meno che non utilizzi i selettori del 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 raggruppamento logico di endpoint come backend per Ingress multi-cluster.
  • Gestisce il ciclo di vita del NEG per un determinato cluster e applicazione.
  • Viene creato come servizio headless. Tieni presente che solo i campi Selector e Ports vengono trasferiti da MultiClusterService al servizio derivato.
  • Il controller Ingress gestisce il proprio 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 corrisponde al traffico verso l'indirizzo IP virtuale su foo.example.com e bar.example.com inviando questo traffico al MultiClusterService risorse 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 viene selezionato esplicitamente da un MultiClusterService, non verrà creato un servizio derivato corrispondente in per 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 in gke-cfg, gke-eu e gke-us cluster GKE. L'identicità dello spazio dei nomi considera lo spazio dei nomi blue sia uguale 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'identicità dello spazio dei nomi significa anche che le risorse di servizio con lo stesso nome più cluster nello spazio dei nomi blue sono considerati lo stesso servizio.

Il gateway tratta il servizio come un unico pool di endpoint in tutti e tre cluster. Poiché le route e le risorse MultiClusterIngress possono essere instradate servizi all'interno dello stesso spazio dei nomi, questo fornisce un'architettura multi-tenancy coerente su 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 fornisce e coerenza tra i cluster.

Considera i seguenti principi di progettazione per l'identicità 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 dello spazio dei nomi o implicitamente, tramite criteri fuori banda, per i team 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 accidentalmente il deployment delle risorse nello spazio dei nomi predefinito e violare 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. Sei tu a scegliere il livello di configurazione del cluster quando abiliti Ingress multi-cluster. Puoi scegliere qualsiasi Cluster GKE come cluster di configurazione e modifica la configurazione in qualsiasi momento.

Disponibilità del cluster di configurazione

Poiché il cluster di configurazione è un singolo punto di controllo, le risorse Ingress multi-cluster Impossibile creare o aggiornare 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 ad alta disponibilità. I cluster a livello di regione sono da preferire rispetto a quelli a livello di zona.
  • Per abilitare Ingress multi-cluster, non è necessario che il cluster di configurazione un cluster dedicato. Il cluster di configurazione può ospitare carichi di lavoro delle applicazioni, ma dovresti assicurarti che le applicazioni in hosting non influisce sulla disponibilità del server API del cluster di configurazione. La configurazione un cluster può essere un cluster di destinazione che ospita i backend per MultiClusterService ma se sono necessarie ulteriori precauzioni, il cluster di configurazione può 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 distribuiscono Ingress in più cluster devono avere accesso a il cluster di configurazione per eseguire il deployment di MultiClusterIngress e MultiClusterService Google Cloud. 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 abiliti Ingress multi-cluster. Qualsiasi membro di un parco risorse può essere selezionato come cluster di configurazione. Puoi aggiornare la configurazione cluster in qualsiasi momento, ma deve assicurarsi che non causi e un'interruzione del servizio. Il controller Ingress riconcilia le risorse presenti in del cluster di configurazione. Durante la migrazione del cluster di configurazione da quella corrente a quella successiva, MultiClusterIngress e MultiClusterService risorse devono essere identiche. Se le risorse non sono identiche, i bilanciatori del carico Compute Engine può essere aggiornato o eliminato dopo l'aggiornamento del cluster di configurazione.

Il seguente diagramma mostra come si applica un sistema CI/CD centralizzato MultiClusterIngress e MultiClusterService alle risorse Server API GKE per il cluster di configurazione (gke-us) e un cluster di backup (gke-eu) in modo che le risorse siano identiche tra i due cluster. Puoi modificare il cluster di configurazione per le emergenze tempi di inattività pianificati in qualsiasi momento senza alcun impatto, poiché il MultiClusterIngress e MultiClusterService risorse sono identiche.

Selezione del cluster

MultiClusterService risorse possono selezionare tra i cluster. Per impostazione predefinita, 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 a MultiClusterService risorse 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 il routing ai backend che su cluster diversi.

Devi assicurarti che i cluster membro all'interno dello stesso parco risorse e della stessa regione nomi univoci per evitare collisioni di nomi.

Per scoprire come configurare la selezione del cluster, consulta Configurazione di Ingress multi-cluster.

Il seguente file manifest descrive un MultiClusterService con 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 nell'elemento gke-asia e gke-eu cluster 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 manutenzione o altre operazioni.

Passaggi successivi