Connettiti ai cluster registrati con il gateway Connect

I parchi risorse in Google Cloud sono gruppi logici di cluster Kubernetes e altre risorse che possono essere gestiti insieme, creati registrando i cluster in Google Cloud. Il gateway Connect si basa sulla potenza dei parchi risorse per consentire agli utenti di GKE Enterprise di connettersi ed eseguire comandi sui cluster membri del parco risorse in modo semplice, coerente e sicuro, che i cluster si trovino su Google Cloud, altri cloud pubblici o on-premise, e semplifica l'automazione dei processi DevOps in tutti i tuoi cluster.

Questa guida presuppone che tu abbia già familiarità con alcuni concetti di base del parco risorse e con la registrazione dei cluster in un parco risorse. In caso contrario, puoi scoprire di più nella panoramica della gestione del parco risorse, nella panoramica della creazione del parco risorse e nelle relative guide collegate. Inoltre, dovresti avere familiarità con gli strumenti e i concetti di Kubernetes, tra cui kubectl, client-go (se vuoi utilizzare il gateway per scopi di automazione), controllo dell'accesso basato sui ruoli (RBAC) e le risorse Kubernetes principali.

Per impostazione predefinita, il gateway Connect utilizza il tuo ID Google per eseguire l'autenticazione sui cluster, con il supporto di provider di identità di terze parti che utilizzano la federazione delle identità per la forza lavoro e con il supporto dell'autenticazione basata su gruppi tramite GKE Identity Service. Per saperne di più su GKE Identity Service o utilizzarlo come opzione di autenticazione autonoma di terze parti, consulta Introduzione a GKE Identity Service.

Perché utilizzare il gateway Connect?

La gestione dei carichi di lavoro presenta molte sfide quando i cluster sono in esecuzione in più cloud e ambienti ibridi. I cluster potrebbero essere in esecuzione in diversi VPC (Virtual Private Cloud) e sfruttare diversi provider di identità, rendendo più complicate connettività, autenticazione e autorizzazione. A volte, scoprire semplicemente quali cluster esistono in questi ambienti è difficile.

Il gateway Connect semplifica le seguenti operazioni:

  • Scopri quali cluster esistono (su Google Cloud, su un altro cloud pubblico o on-premise) e sono registrati nel tuo parco risorse tramite una semplice query.
  • Connettiti a un cluster desiderato utilizzando la stessa infrastruttura che utilizziamo per visualizzare i cluster GKE registrati nella console Google Cloud.
  • Esegui l'autenticazione utilizzando le stesse identità che utilizzi con i servizi Google Cloud.
  • Autorizza in modo coerente in tutti i cluster registrati in un parco risorse.

Il gateway autentica la tua identità Google Cloud e fornisce la connessione al server API del cluster tramite il servizio Connect.

Puoi interagire con i cluster direttamente attraverso il gateway utilizzando strumenti a riga di comando che accettano un kubeconfig, come kubectl. Puoi anche sfruttare facilmente il gateway con le tue pipeline di build e altre operazioni di automazione DevOps. Puoi visualizzare un esempio di come eseguire questa operazione nel nostro tutorial sull'integrazione con Cloud Build.

Puoi anche utilizzare il servizio Connect per connetterti a cluster registrati esterni a Google Cloud con la tua identità Google Cloud nella console Google Cloud. Per farlo, segui le istruzioni in Accedere a un cluster dalla console Google Cloud.

Come funziona

Ecco il flusso che un utente o un servizio tipico (ad esempio una pipeline CI/CD) esegue per utilizzare il gateway Connect, dopo aver configurato l'autenticazione e l'autorizzazione appropriate. Per istruzioni più dettagliate, consulta la nostra guida all'utilizzo.

  1. L'utente o il servizio rileva i cluster elencando le risorse di abbonamento del parco risorse con Google Cloud CLI.

    gcloud container fleet memberships list

  2. L'utente o il servizio recupera l'elemento kubeconfig specifico del gateway Connect necessario per raggiungere il cluster selezionato utilizzando Google Cloud CLI.

    gcloud container fleet memberships get-credentials membership-name

    Se hai già familiarità con l'utilizzo di gcloud CLI con GKE, è un po' come eseguire gcloud container clusters get-credentials con il tuo account Google Cloud e ti permette (se hai l'autorizzazione) di accedere a qualsiasi cluster registrato e connesso all'interno del parco risorse del tuo progetto.

  3. L'utente o il servizio esegue i comandi come farebbe normalmente con kubectl o client-go, utilizzando il file kubeconfig scaricato.

    1. L'utente/servizio viene autenticato dal gateway Connect e l'autorizzazione viene verificata per garantire che disponga dell'autorizzazione per utilizzare il gateway.
    2. La richiesta viene inoltrata tramite il servizio Connect e l'agente Connect al server API Kubernetes corrispondente.
    3. Il server API Kubernetes autorizza la richiesta, il che richiede che l'agente Connect sia autorizzato a impersonare l'utente o il servizio e che l'utente o il servizio sia autorizzato a eseguire la richiesta desiderata.

Assistenza per Google Gruppi

Nel flusso standard descritto nella sezione precedente, la richiesta dell'utente viene autorizzata in base al suo ID individuale. Tuttavia, in molti casi è utile essere in grado di autorizzare gli utenti in base alla loro appartenenza a Google Gruppi. Autorizzare in base all'appartenenza ai gruppi significa che non devi impostare un'autorizzazione separata per ciascun account, il che rende i criteri più semplici da gestire e più facili da controllare. Quindi, ad esempio, puoi facilmente condividere l'accesso a un cluster con un team, eliminando la necessità di aggiungere/rimuovere manualmente i singoli utenti dai cluster quando entrano a far parte del team o lo lasciano. Con alcune configurazioni aggiuntive mediante GKE Identity Service, puoi configurare il gateway Connect in modo da ricevere per l'utente informazioni sull'iscrizione ai gruppi Google.

Per saperne di più su come funziona questa funzionalità e come configurarla, consulta Configurare il gateway di Connect con Google Gruppi.

Se vuoi utilizzare questa funzionalità con cluster collegati o altri ambienti GKE Enterprise, contatta l'assistenza clienti Google Cloud o il team del gateway Connect.

Assistenza per l'identità di terze parti

Oltre a lavorare con utenti e gruppi di Google Workspace, il gateway Connect supporta l'autorizzazione tramite identità di terze parti, come Azure Active Directory e Okta. Utilizzando la federazione delle identità per la forza lavoro, puoi utilizzare un provider di identità esterno per autenticare e autorizzare una forza lavoro, ovvero un gruppo di utenti, ad esempio dipendenti, partner e contrattisti, utilizzando Identity and Access Management, in modo che gli utenti possano accedere ai servizi Google Cloud come Connect Gateway. Con alcune configurazioni aggiuntive mediante GKE Identity Service, puoi configurare il gateway Connect in modo da ricevere per gli utenti informazioni sull'iscrizione a gruppi di terze parti.

La funzionalità di identità di terze parti del gateway Connect è supportata per i deployment Google Distributed Cloud su VMware e on bare metal a partire da Anthos (GKE Enterprise) dalla versione 1.13 in poi. Per i cluster collegati, questa funzionalità è disponibile da Anthos 1.16 e versioni successive.

Per saperne di più su come funziona questa funzionalità e come configurarla, consulta l'articolo Configurare il gateway Connect con identità di terze parti.

Se preferisci, puoi configurare l'autenticazione di terze parti interamente utilizzando GKE Identity Service seguendo le istruzioni nella relativa documentazione.

Latenza

La latenza totale di una richiesta tramite il gateway può essere suddivisa in due parti: il tempo di round trip (RTT) dal servizio gateway Connect all'agente Connect e il tempo di esecuzione della richiesta all'interno del cluster. La latenza aggiuntiva offerta da RTT è p95<500ms e p99<1s. Tieni presente che la maggior parte dei comandi kubectl esegue una serie di diverse richieste, ciascuna delle quali richiede un round trip, prima di visualizzare una risposta all'utente.

Che cosa succede dopo?