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 e che vengono 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 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, 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 scoprire di più su GKE Identity Service o utilizzarlo come opzione di autenticazione di terze parti autonoma, consulta Introduzione a GKE Identity Service.

Perché utilizzare Connect Gateway?

La gestione dei carichi di lavoro presenta molte sfide quando i cluster sono in esecuzione in più cloud e ambienti ibridi. I cluster possono essere in esecuzione in diversi cloud virtual private (VPC) e utilizzare diversi provider di identità, rendendo più complesse la connettività, l'autenticazione e l'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 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 a cluster registrati esterni a Google Cloud con la tua identità Google Cloud nella console Google Cloud. A tale scopo, segui le istruzioni riportate in Lavorare con 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 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à dimestichezza con l'utilizzo della CLI gcloud 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 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 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. 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 alcune configurazioni aggiuntive mediante GKE Identity Service, puoi configurare il gateway Connect in modo da ottenere per l'utente informazioni sull'iscrizione ai gruppi Google.

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 gateway di Connect.

Assistenza per l'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. Con 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 servizi Google 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 Deployment di Google Distributed Cloud on 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 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 completamente l'autenticazione di terze parti utilizzando 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 round trip (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<500ms e p99<1s. 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