Ingress multi-cluster

Ingress multi-cluster è un controller ospitato nel cloud per i cluster Google Kubernetes Engine (GKE). È un servizio ospitato da Google che supporta il deployment di risorse di bilanciamento del carico condivise nei cluster e tra regioni. Per eseguire il deployment di Ingress multi-cluster su più cluster, completa Configurazione di Ingress multi-cluster, quindi consulta Deployment di Ingress su 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 NEG autonomi), consulta Scegliere l'API di bilanciamento del carico multi-cluster per GKE.

Networking multi-cluster

Molti fattori determinano le topologie multi-cluster, tra cui la vicinanza degli utenti per app, l'alta disponibilità a livello di cluster e a livello di regione, la separazione della sicurezza e dell'organizzazione, la migrazione dei cluster e la località dei dati. Questi casi d'uso sono raramente isolati. Man mano che crescono le ragioni della presenza di più cluster, diventa sempre più urgente la necessità di una piattaforma multi-cluster formale e prodottizzata.

Ingress multi-cluster è progettato per soddisfare le esigenze di bilanciamento del carico degli ambienti multi-cluster e multiregionali. Rappresenta un controller per il bilanciatore del carico HTTP(S) esterno, che fornisce il traffico in entrata per il traffico proveniente da internet attraverso uno o più cluster.

Il supporto multi-cluster di Ingress multi-cluster soddisfa molti casi d'uso, tra cui:

  • Un singolo IP virtuale (VIP) coerente per un'app, indipendentemente dal luogo in cui viene eseguito il deployment dell'app a livello globale.
  • Disponibilità multi-cluster e su più regioni tramite controllo di integrità e failover del traffico.
  • Routing basato su prossimità tramite VIP Anycast pubblici per una bassa latenza del client.
  • Migrazione trasparente del cluster per upgrade o nuove build dei cluster.

Quote predefinite

Ingress multi-cluster ha le seguenti quote predefinite:

  • Per maggiori dettagli sui limiti dei membri per i parchi risorse, consulta Quote di gestione del parco risorse. Per sapere quanti membri sono supportati in un parco risorse.
  • 100 risorse MultiClusterIngress e 100 risorse MultiClusterService per progetto. Puoi creare fino a 100 risorse MultiClusterIngress e 100 MultiClusterService in un cluster di configurazione per un numero qualsiasi di cluster di backend fino al numero massimo di cluster 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 multi-cluster si basa sull'architettura dell'Application Load Balancer esterno globale. L'Application Load Balancer esterno globale è un bilanciatore del carico distribuito a livello globale con proxy il cui deployment è stato eseguito in oltre 100 POP Google in tutto il mondo. Questi proxy, denominati GFE (Google Front End), si trovano sul perimetro della rete Google, vicini ai client. La funzionalità Ingress multi-cluster crea bilanciatori del carico delle applicazioni esterni nel livello Premium. Questi bilanciatori del carico utilizzano indirizzi IP esterni globali pubblicizzati utilizzando anycast. Le richieste vengono gestite dai GFE e dal cluster più vicino al client. Il traffico internet passa al punto di accesso Google più vicino e utilizza il backbone di Google per accedere a un cluster GKE. Questa configurazione del bilanciamento del carico riduce la latenza dal client al GFE. Puoi anche ridurre la latenza tra la gestione di cluster GKE e GFE eseguendo i tuoi cluster GKE nelle regioni più vicine ai tuoi client.

La terminazione delle connessioni HTTP e HTTPS a livello perimetrale consente al bilanciatore del carico di Google di decidere dove instradare 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 viene gestito in modo più efficiente dal client al backend, tenendo conto dell'integrità e della capacità dei backend.

Ingress multi-cluster è un controller Ingress che programma il bilanciatore del carico HTTP(S) esterno utilizzando i gruppi di endpoint di rete (NEG). Quando crei una risorsa MultiClusterIngress, GKE esegue il deployment delle risorse del bilanciatore del carico di Compute Engine e configura i pod appropriati nei cluster come backend. I NEG vengono utilizzati per monitorare gli endpoint dei pod in modo dinamico, in modo che il bilanciatore del carico di Google abbia l'insieme corretto di backend in stato integro.

Flusso di traffico in Ingress multi-cluster

Durante il deployment delle applicazioni nei cluster in GKE, la risorsa Ingress multi-cluster assicura 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 e non supera il controllo di integrità.
  • Un cluster viene rimosso dal pool di backend.

L'impostazione Ingress multi-cluster aggiorna il bilanciatore del carico, mantenendolo coerente con l'ambiente e lo stato desiderato delle risorse Kubernetes.

Architettura in Ingress multi-cluster

L'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 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 controller Ingress multi-cluster esegue il deployment di bilanciatori del carico su più cluster.

I seguenti concetti e componenti compongono il 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. In questo modo, il ciclo di vita e le operazioni del controller sono indipendenti dai cluster GKE.

  • Cluster di configurazione: si tratta di un cluster GKE scelto in esecuzione su Google Cloud in cui viene eseguito il deployment delle risorse MultiClusterIngress e MultiClusterService. È 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 tra tutti i cluster. Il controller Ingress controlla il cluster di configurazione e riconcilia l'infrastruttura di bilanciamento del carico.

  • Un parco risorse consente di raggruppare e normalizzare logicamente i cluster GKE, semplificando l'amministrazione dell'infrastruttura e abilitando 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 del parco risorse. Un cluster può essere membro di un solo parco risorse.

  • Cluster 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 è consapevole l'Ingress multi-cluster. La vista Gestione dei cluster di Google Kubernetes Engine fornisce una console sicura per visualizzare lo stato di tutti i cluster registrati.

Architettura in Ingress multi-cluster

Flusso di lavoro di 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. 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.

  3. Esegui il deployment delle applicazioni nei cluster GKE dove devono essere eseguite.

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

  5. Esegui il deployment di una risorsa MultiClusterIngress nel cluster di configurazione che fa riferimento a una o più risorse MultiClusterService come backend per il bilanciatore del carico. Questa operazione esegue il deployment delle risorse del bilanciatore del carico esterno di Compute Engine ed espone gli endpoint nei vari cluster tramite un singolo VIP del bilanciatore del carico.

Concetti di Ingress

Ingress multi-cluster utilizza un server API Kubernetes centralizzato per eseguire il deployment di Ingress in più cluster. Le seguenti sezioni descrivono il modello di risorse Ingress multi-cluster, la modalità di 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 cluster. Una risorsa MultiClusterService seleziona i pod, in modo simile alla risorsa Servizio, ma una risorsa MultiClusterService può anche selezionare etichette e cluster. Il pool di cluster selezionati da MultiClusterService è chiamato cluster membri. Tutti i cluster registrati nel parco risorse sono cluster membri.

Un MultiClusterService esiste solo nel cluster di configurazione e non indirizza nessuna modalità come un servizio ClusterIP, LoadBalancer o NodePort. Consente invece al controller Ingress multi-cluster di fare riferimento a una singola risorsa distribuita.

Il seguente file manifest di esempio descrive un oggetto 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 sono presenti pod app: foo, gli indirizzi IP dei pod 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. Esisteranno un servizio derivato e un NEG in ogni cluster di destinazione per ogni MultiClusterService (a meno che non vengano utilizzati selettori di cluster). Se non esistono pod corrispondenti 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 è quella di raggruppamento logico di endpoint come backend per Ingress 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 e Ports vengono trasferiti da MultiClusterService al servizio derivato.
  • Il controller Ingress ne gestisce il ciclo di vita.

Risorsa MultiClusterIngress

Una risorsa MultiClusterIngress si comporta in modo identico in molti modi alla risorsa Ingress principale. Entrambi hanno le stesse specifiche per definire host, percorsi, terminazione di protocollo e backend.

Il seguente file manifest descrive un elemento MultiClusterIngress che instrada il traffico ai backend foo e bar in base alle 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 al backend predefinito MultiClusterService.

Il seguente diagramma mostra il flusso del traffico da un traffico in entrata a un cluster:

Nel diagramma sono presenti due cluster, gke-us e gke-eu. Il traffico passa da foo.example.com ai pod con l'etichetta app:foo in entrambi i cluster. Da bar.example.com, il traffico passa ai pod che hanno l'etichetta app:bar in entrambi i cluster.

Risorse in entrata nei cluster

Il cluster di configurazione è l'unico cluster che può avere risorse MultiClusterIngress e MultiClusterService. Ogni cluster di destinazione che contiene pod che corrispondono ai selettori di etichette MultiClusterService dispone anche di un servizio derivato corrispondente pianificato. Se un cluster non viene selezionato esplicitamente da un MultiClusterService, il servizio derivato corrispondente non viene creato in quel cluster.

Uniformità dello spazio dei nomi

L'identicità dello spazio dei nomi è una proprietà dei cluster Kubernetes in cui uno spazio dei nomi si estende su più cluster ed è considerato lo stesso spazio dei nomi.

Nel diagramma seguente, lo spazio dei nomi blue esiste nei cluster GKE gke-cfg, gke-eu e gke-us. L'equivalenza dello spazio dei nomi considera lo spazio dei nomi blue 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 in più cluster nello spazio dei nomi blue sono considerate come lo stesso servizio.

Il gateway tratta il servizio come un singolo pool di endpoint nei tre cluster. Poiché le risorse Route e MultiClusterIngress possono essere instradate ai servizi solo all'interno dello stesso spazio dei nomi, questa opzione offre una multitenancy coerente per la configurazione in tutti i cluster del parco risorse. I parchi risorse offrono un elevato livello di portabilità poiché le risorse possono essere distribuite o spostate tra cluster senza alcuna modifica alla configurazione. Il deployment nello stesso spazio dei nomi del parco risorse offre coerenza tra i cluster.

Considera i seguenti principi di progettazione per l'uguaglianza dello spazio dei nomi:

  • Gli spazi dei nomi per scopi diversi non devono avere lo stesso nome in tutti i cluster.
  • Gli spazi dei nomi devono essere riservati in modo esplicito, assegnando uno spazio dei nomi o implicitamente, tramite criteri fuori banda per i team e i cluster all'interno di un parco risorse.
  • Gli spazi dei nomi con lo stesso scopo nei vari cluster devono condividere lo stesso nome.
  • L'autorizzazione degli utenti per gli spazi dei nomi nei cluster deve essere strettamente controllata per impedire l'accesso non autorizzato.
  • Non devi utilizzare lo spazio dei nomi predefinito o spazi dei nomi generici come "prod" o "dev" per il normale deployment dell'applicazione. Gli utenti non possono eseguire accidentalmente il deployment delle risorse nello spazio dei nomi predefinito e violano i principi di segmentazione degli spazi dei nomi.
  • Lo stesso spazio dei nomi deve essere creato nei cluster ogni volta che 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 funge da singolo punto di controllo per Ingress nel parco risorse di cluster GKE di destinazione. Puoi scegliere il cluster di configurazione quando abiliti Ingress multi-cluster. Puoi scegliere qualsiasi cluster GKE come cluster di configurazione e modificare il cluster di configurazione in qualsiasi momento.

Disponibilità del 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 del cluster di configurazione non è disponibile. I bilanciatori del carico e il traffico da loro gestito 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 sarà nuovamente disponibile.

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 preferiti rispetto ai cluster di zona.
  • Per abilitare Ingress multi-cluster, il cluster di configurazione non deve essere un cluster dedicato. Il cluster di configurazione potrebbe ospitare carichi di lavoro amministrativi o anche delle applicazioni, ma dovresti 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 backend per le risorse MultiClusterService. Tuttavia, 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 dai backend dei cluster di destinazione. Una risorsa MultiClusterService può fare riferimento solo ai pod nello stesso spazio dei nomi tra i cluster, in modo che lo spazio dei nomi deve 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 e MultiClusterService. Tuttavia, gli utenti devono avere accesso solo agli spazi dei nomi per i quali sono autorizzati a utilizzare.

Selezione e migrazione del cluster di configurazione

Devi scegliere il cluster di configurazione quando abiliti Ingress multi-cluster. Qualsiasi cluster membro di un parco risorse può essere selezionato come cluster di configurazione. Puoi aggiornare il cluster di configurazione in qualsiasi momento, ma devi assicurarti che non causi interruzioni. Il controller Ingress riconcilia 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, i bilanciatori del carico di Compute Engine possono essere aggiornati o eliminati dopo l'aggiornamento del cluster di configurazione.

Il seguente diagramma mostra in che modo un sistema CI/CD centralizzato applica 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 tempi di inattività pianificati in qualsiasi momento senza alcun impatto, poiché le risorse MultiClusterIngress e MultiClusterService sono identiche.

Selezione del cluster

MultiClusterService risorse che possono essere selezionate nei cluster. Per impostazione predefinita, il controller pianifica un servizio derivato su ogni cluster di destinazione. Se non vuoi un servizio derivato su ogni cluster di destinazione, puoi definire un elenco di cluster utilizzando il campo spec.clusters nel manifest MultiClusterService.

Ti consigliamo di definire un elenco di cluster se devi:

  • Isola il cluster di configurazione per impedire la selezione di risorse MultiClusterService nel cluster di configurazione.
  • Controlla il traffico tra i cluster per la migrazione delle applicazioni.
  • Instrada a backend di applicazioni che esistono solo in un sottoinsieme di cluster.
  • Utilizza un singolo indirizzo IP virtuale HTTP(S) per il routing a backend che risiedono su cluster diversi.

Devi assicurarti che i cluster membri nello stesso parco risorse e nella stessa regione abbiano nomi univoci per evitare conflitti di denominazione.

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

Il seguente file manifest descrive un elemento 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 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 sono esclusi anche se hanno pod con l'etichetta app: foo.

Il seguente diagramma mostra una configurazione di MultiClusterService di esempio utilizzando 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, poiché il cluster non è incluso nell'elenco del manifest spec.clusters. Il cluster non riceve traffico per manutenzione o altre operazioni.

Passaggi successivi