Connettiti ai cluster registrati con il gateway Connect

I fleet 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, indipendentemente dal fatto che i cluster si trovino su Google Cloud, su altri cloud pubblici o on-premise e semplifica l'automazione delle procedure DevOps in tutti i cluster.

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

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

Perché utilizzare Connect Gateway?

Esistono molte sfide nella gestione dei carichi di lavoro quando i cluster sono in esecuzione in più cloud ed ambienti ibridi. I cluster possono essere in esecuzione in diversi cloud privati virtuali (VPC) e utilizzare diversi provider di identità, complicando la connettività, l'autenticazione e l'autorizzazione. A volte è difficile anche solo scoprire quali cluster esistono in questi ambienti.

Connect Gateway semplifica:

  • Scopri quali cluster esistono (su Google Cloud, su un altro cloud pubblico o on-premise) e sono registrati al 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 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 direttamente con i cluster tramite il gateway utilizzando strumenti a riga di comando che accettano un kubeconfig come kubectl. Puoi anche utilizzare facilmente il gateway con le pipeline di compilazione e altre automazioni DevOps. Puoi vedere un esempio di come eseguire questa operazione nel nostro tutorial sull'integrazione con Cloud Build.

Puoi anche utilizzare il servizio Connect per connetterti ai cluster registrati al di fuori di Google Cloud con la tua identità Google Cloud nella console Google Cloud . Per farlo, segui le istruzioni riportate in Utilizzare i cluster dalla console Google Cloud .

Come funziona

Di seguito è riportato il flusso eseguito da un utente o un servizio tipico (ad esempio una pipeline CI/CD) per utilizzare Connect Gateway dopo aver configurato l'autenticazione e l'autorizzazione appropriate. Per istruzioni utente più dettagliate, consulta la nostra guida all'utilizzo.

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

    gcloud container fleet memberships list

  2. L'utente o il servizio recupera il token kubeconfig specifico di Connect Gateway necessario per raggiungere il cluster selezionato utilizzando lGoogle Cloud CLI.

    gcloud container fleet memberships get-credentials membership-name

    Se hai già dimestichezza con l'utilizzo della gcloud CLI con GKE, questa operazione è simile all'esecuzione di gcloud container clusters get-credentials utilizzando il tuo account Google Cloud , che ti consente (se autorizzato) 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/il servizio viene autenticato da Connect Gateway e l'autorizzazione viene verificata per verificare che l'utente/il servizio abbia l'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, che richiede che l'agente Connect sia autorizzato a rubare l'identità dell'utente o del servizio e che l'utente o il servizio sia autorizzato a eseguire la richiesta desiderata.

Assistenza di Google Gruppi

Nel flusso standard descritto nella sezione precedente, la richiesta dell'utente viene autorizzata in base al suo ID personale. Tuttavia, in molti casi è utile poter autorizzare gli utenti in base alla loro appartenenza a Google Gruppi. L'autorizzazione in base all'appartenenza al gruppo significa che non devi configurare un'autorizzazione separata per ogni account, il che semplifica la gestione e il controllo dei criteri. Ad esempio, puoi condividere facilmente l'accesso ai 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 una configurazione aggiuntiva utilizzando GKE Identity Service, puoi configurare Connect Gateway in modo da ottenere le informazioni sull'appartenenza a Google Gruppi per l'utente.

Per scoprire di più sul funzionamento e sulla configurazione di questa funzionalità, consulta Configurare il gateway 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 di Connect Gateway.

Supporto per le identità di terze parti

Oltre a lavorare con gli utenti e i gruppi di Google Workspace, Connect Gateway supporta l'autorizzazione utilizzando identità di terze parti, come Azure Active Directory e Okta. Utilizzando la federazione delle identità della forza lavoro, puoi utilizzare un provider di identità esterno per autenticare e autorizzare una forza lavoro, ovvero un gruppo di utenti come dipendenti, partner e appaltatori, utilizzando Identity and Access Management, in modo che gli utenti possano accedere ai serviziGoogle Cloud come Connect Gateway. Con una configurazione aggiuntiva che utilizza GKE Identity Service, puoi configurare il gateway Connect per ottenere informazioni sull'appartenenza ai gruppi di terze parti per gli utenti.

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

Per scoprire di più sul funzionamento e sulla configurazione di questa funzionalità, consulta l'articolo Configurare il gateway Connect con identità di terze parti.

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

Latenza

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

Passaggi successivi