Ingress multi-cluster

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 in tutti i cluster e tra le regioni. Per eseguire il deployment di Ingress multi-cluster su più cluster, completa la sezione Configurazione di Ingress multi-cluster, quindi consulta la sezione Deployment di Ingress in più cluster.

Networking multi-cluster

Molti fattori determinano le topologie multi-cluster, tra cui la vicinanza degli utenti per app, alta disponibilità a livello di cluster e a livello di area geografica, sicurezza e separazione organizzativa, migrazione dei cluster e località dei dati. Questi casi d'uso sono raramente isolati. Man mano che i motivi di più cluster crescono, la necessità di una piattaforma multi-cluster formale e prodotto diventa più urgente.

Ingress multi-cluster è progettato per soddisfare le esigenze di bilanciamento del carico di ambienti multi-cluster e multiregionali. È un controller per il bilanciatore del carico HTTP(S) esterno che fornisce il traffico in entrata per il traffico proveniente da Internet in uno 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 viene eseguito il deployment dell'app a livello globale.
  • Disponibilità multiregionale e multi-cluster tramite controllo di integrità e failover del traffico.
  • Routing basato sulla prossimità tramite VIP anycast pubblici per una bassa latenza del client.
  • Migrazione trasparente dei cluster per gli upgrade o le ricostruzioni di cluster.

Quote predefinite

Le risorse Ingress multi-cluster hanno 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 100 MultiClusterService in un cluster di configurazione per un numero qualsiasi di cluster di backend fino al massimo del cluster per progetto.

Contatta il tuo supporto se hai bisogno di aumentare queste quote.

Prezzi e prove

Per ulteriori informazioni sui prezzi di Ingress per più cluster, consulta Prezzi di Ingress in più cluster.

Come funziona Ingress multi-cluster

Ingress multi-cluster si basa sull'architettura del bilanciatore del carico HTTP(S) esterno globale. Il bilanciatore del carico HTTP(S) esterno globale è un bilanciatore del carico distribuito a livello globale con proxy distribuiti in più di 100 punti di presenza Google (PoP) in tutto il mondo. Questi proxy, chiamati Google Front End (GFE), si trovano sul perimetro della rete di Google e sono vicini ai client. Ingress multi-cluster crea bilanciatori del carico HTTP(S) esterni nel livello Premium. Questi bilanciatori del carico utilizzano indirizzi IP esterni globali pubblicizzati con anycast. Le richieste vengono gestite dai GFE e dal cluster più vicino al client. Il traffico Internet va al POP di Google più vicino e utilizza la backbone di Google per raggiungere un cluster GKE. Questa configurazione di bilanciamento del carico comporta una latenza inferiore dal client al GFE. Puoi anche ridurre la latenza tra la gestione di cluster GKE e di GFE eseguendo i tuoi cluster GKE nelle regioni più vicine ai tuoi client.

La terminazione delle connessioni HTTP e HTTPS a livello periferico consente al bilanciatore del carico di Google di decidere dove indirizzare il traffico determinando la disponibilità del backend prima che il traffico entri in un data center o in un'area geografica. Questo offre al traffico il percorso più efficiente dal client al backend tenendo conto della capacità e dell'integrità dei backend.

Il Ingress 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 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 il giusto insieme di backend integri.

Flusso di traffico Ingress multi-cluster

Quando esegui il deployment di applicazioni nei cluster in GKE, Multi Cluster Ingress assicura che il bilanciatore del carico sia sincronizzato con gli eventi che si verificano nel cluster:

  • Un deployment viene creato con le etichette corrispondenti corrispondenti.
  • Il processo di un pod muore e non supera il controllo di integrità.
  • Un cluster viene rimosso dal pool di backend.

Ingress multi-cluster aggiorna il bilanciatore del carico, mantenendo la coerenza con l'ambiente e lo stato desiderato delle risorse Kubernetes.

Architettura Ingress multi-cluster

Ingress multi-cluster utilizza un server API Kubernetes centralizzato per 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. Con il deployment di queste risorse sul cluster di configurazione, il controller Ingress multi-cluster esegue il deployment di bilanciatori del carico su più cluster.

I seguenti concetti e componenti compongono Ingress multi-cluster:

  • Controller Ingress in più cluster: un piano di controllo distribuito a livello globale che viene eseguito come servizio al di fuori dei cluster. Ciò consente al ciclo di vita e alle operazioni del controller di essere indipendenti dai cluster GKE.

  • Cluster di configurazione - Questo è un cluster GKE scelto in esecuzione su Google Cloud dove viene eseguito il deployment delle risorse MultiClusterIngress e MultiClusterService. Questo è un punto di controllo centralizzato per le 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.

  • Un floreale 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 denominati cluster membri. I cluster membri del parco risorse comprendono l'ambito completo dei backend di cui il Ingress multi-cluster è a conoscenza. La vista per la gestione dei cluster di Google Kubernetes Engine fornisce una console sicura per visualizzare lo stato di tutti i tuoi cluster registrati.

Arco Ingress multi-cluster

Flusso di lavoro di 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 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 oppure può eseguire altri carichi di lavoro.

  3. Eseguire il deployment delle applicazioni nei cluster GKE in cui devono essere eseguiti.

  4. 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 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. Questo esegue il deployment delle risorse del bilanciatore del carico esterno di Compute Engine ed espone gli endpoint nei cluster attraverso un singolo VIP del bilanciatore del carico.

Concetti in entrata

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

Risorse MultiClusterService

Una risorsa MultiClusterService è una risorsa personalizzata utilizzata da Ingress multi-cluster per rappresentare i servizi di condivisione tra i cluster. Una risorsa MultiClusterService seleziona i pod, in modo simile alla risorsa Servizio, ma anche MultiClusterService può selezionare etichette e cluster. Il pool di cluster che MultiClusterService seleziona tra questi sono chiamati cluster membri. Tutti i cluster registrati nel parco risorse sono cluster membri.

MultiClusterService è presente solo nel cluster di configurazione e non esegue il routing di elementi quali un servizio ClusterIP, LoadBalancer o NodePort. Consente invece 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 di membri con il selettore app: foo. Se nel pod esistono app: foo pod, gli indirizzi IP dei pod vengono aggiunti come backend per il 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 etichetta specificato in questo cluster. Un Service e un NEG derivati saranno presenti in ogni cluster di destinazione ogni MultiClusterService (a meno che non si utilizzino i selettori del cluster). Se in un cluster di destinazione non esistono pod corrispondenti, 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 è un raggruppamento logico di endpoint come backend per Ingress multi-cluster.
  • Gestisce il ciclo di vita del NEG per un determinato cluster e una determinata 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 rispetto alla risorsa Ingress principale. Entrambi hanno le stesse specifiche per definire gli host, i percorsi, la terminazione del protocollo e i backend.

Il manifest seguente descrive un MultiClusterIngress che instrada il traffico ai backend foo e bar in base alle intestazioni 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 che corrisponde a tutto il resto del traffico e lo invia al backend predefinito MultiClusterService.

Il seguente diagramma mostra come il traffico passa da una risorsa Ingress a un cluster:

Nel diagramma ci sono due cluster, gke-eu e gke-asia. 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 nei pod con 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 ha pod che corrispondono ai selettori delle etichette MultiClusterService ha anche un servizio derivato corrispondente pianificato. Se un cluster non è selezionato esplicitamente da un MultiClusterService, non viene creato un servizio derivato corrispondente in quel cluster.

Spazio dei nomi uguale

Lo stesso spazio dei nomi è una proprietà dei cluster Kubernetes in cui uno spazio dei nomi si estende tra più cluster e viene 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 come uguale per tutti i cluster. Questo significa che un determinato utente ha gli stessi privilegi nelle risorse nello spazio dei nomi blue in ogni cluster. Lo stesso nome 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 seguente diagramma mostra lo stesso 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 nei tre cluster. Poiché le route e le risorse MultiClusterIngress possono essere instradate solo ai servizi all'interno dello stesso spazio dei nomi, questo fornisce una multitenancy coerente per la configurazione in tutti i cluster del parco risorse. I parchi risorse offrono un'elevata portabilità, in quanto è possibile eseguire il deployment o spostare le risorse tra i cluster senza alcuna modifica alla configurazione. Il deployment nello stesso spazio dei nomi del parco risorse offre coerenza tra i cluster.

Prendi in considerazione 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 esplicitamente, allocando 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 per lo stesso scopo nei cluster dovrebbero 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 spazi dei nomi predefiniti o spazi dei nomi generici come "prod" o "dev" per il normale deployment delle applicazioni. È troppo facile per gli utenti eseguire il deployment di risorse nello spazio dei nomi predefinito per errore e violare i principi di segmentazione degli spazi dei nomi.
  • Lo stesso spazio dei nomi deve essere creato tra i cluster indipendentemente dal fatto che un determinato team o gruppo di utenti debba eseguire il deployment delle risorse.

Progettazione di 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 su tutto il parco 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, le risorse Ingress per il cluster non possono essere create o aggiornate 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 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à. Sono preferiti i cluster a livello di area geografica, anziché quelli di zona.
  • Per abilitare Ingress multi-cluster, il cluster di configurazione non deve essere un cluster dedicato. Il cluster di configurazione può ospitare carichi di lavoro amministrativi o di applicazioni, anche se 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 backend per le risorse MultiClusterService; tuttavia, 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 ai pod solo nello stesso spazio dei nomi nei cluster, in modo che lo spazio dei nomi debba essere presente nel cluster di configurazione.
  • Gli utenti che eseguono il deployment di Ingress in 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 che sono autorizzati a utilizzare.

Selezione ed migrazione del cluster di configurazione

Devi scegliere il cluster di configurazione quando abiliti Multi Cluster Ingress. 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 esistenti nel cluster di configurazione. Durante 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, è possibile che i bilanciatori del carico di Compute Engine vengano aggiornati o eliminati dopo l'aggiornamento del cluster di configurazione.

Il seguente diagramma mostra in che modo un sistema CI/CD centralizzato applica le risorse MultiClusterIngress e MultiClusterService al server API GKE per il cluster di configurazione (gke-us) e per il 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 i tempi di inattività pianificati in qualsiasi momento, senza alcun impatto, perché le risorse MultiClusterIngress e MultiClusterService sono identiche.

Selezione del cluster

MultiClusterService risorse possono essere selezionate nei cluster. Per impostazione predefinita, il controller pianifica un servizio derivato in ogni cluster di destinazione, ignorando tutti gli altri cluster di destinazione.

Per informazioni su come configurare la selezione del cluster, consulta la pagina Configurare Ingress multi-cluster.

Potresti voler applicare regole in entrata a cluster specifici se devi:

  • Isolare il cluster di configurazione per impedire che le risorse MultiClusterService vengano selezionate nel cluster di configurazione.
  • Controlla il traffico tra i cluster per la migrazione delle applicazioni.
  • Instrada ai backend delle applicazioni esistenti solo in un sottoinsieme di cluster.
  • Utilizza un singolo indirizzo IP virtuale HTTP(S) per il routing ai backend che risiedono su diversi cluster.

Puoi definire un elenco di cluster in cui il controller deve pianificare i servizi utilizzando il campo spec.clusters nel manifest MultiClusterService. I cluster fanno riferimento esplicitamente a <region | zone>/<name>. Devi assicurarti che i cluster membri all'interno della stessa flotta e della stessa area geografica abbiano nomi univoci per evitare conflitti di denominazione.

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

Il seguente diagramma mostra una configurazione di esempio MultiClusterService 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 ci sono pod con etichette corrispondenti perché il cluster non è incluso nell'elenco spec.clusters del file manifest. Il cluster non riceve traffico per la manutenzione o altre operazioni.

Passaggi successivi