Ingress multi-cluster

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 risorse MultiClusterService per progetto. Puoi creare fino a 50 risorse MultiClusterIngress 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.

Flusso di traffico Ingress multi-cluster

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 e MultiClusterService. 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.

Arco Ingress multi-cluster

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.

  1. Registra i cluster GKE come cluster di appartenenza.

  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 su cui 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 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.

  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. 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 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 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 MultiClusterServicebackend 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 e MultiClusterService. 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