Gestire i cluster dalla console Google Cloud

Questo documento spiega come rendere disponibile Anthos clusters on bare metal per la gestione nella console Google Cloud. Sono incluse la gestione di base, come la possibilità di accedere ai cluster e visualizzare i relativi carichi di lavoro, nonché come abilitare la gestione del ciclo di vita dei cluster per consentire l'upgrade, l'aggiornamento e l'eliminazione dei cluster.

Membri del parco risorse e console

Tutti Anthos clusters on bare metal devono essere membri di un flotta, un modo unificato per visualizzare e gestire più cluster e i relativi carichi di lavoro. Ogni parco cluster è associato a un progetto host del parco risorse.

In Anthos clusters on bare metal, un cluster utente viene registrato in un parco risorse al momento della creazione:

  • Quando crei un cluster utilizzando bmctl, specifichi il progetto host del tuo parco risorse nella sezione gkeConnect del file di configurazione del cluster. Anthos clusters on bare metal utilizza queste informazioni per registrare il tuo cluster nel progetto del parco risorse specificato.

  • Quando crei un cluster utente nella console, il cluster diventa automaticamente un membro del parco risorse nel progetto selezionato nella console.

I membri del parco risorse esterni a Google Cloud, come Anthos clusters on bare metal, vengono visualizzati nella console nel progetto host del parco risorse, insieme ad altri cluster del parco risorse come GKE su Google Cloud. La possibilità di gestire Anthos clusters on bare metal dalla console dipende da quanto segue:

  • Se hai configurato l'autenticazione, puoi accedere ai tuoi cluster e visualizzare i relativi carichi di lavoro e altri dettagli.

  • Se hai attivato la gestione del ciclo di vita del cluster per il cluster, puoi anche eseguire l'upgrade, l'aggiornamento o l'eliminazione dei cluster utente utilizzando la console. A questo scopo, il cluster deve essere gestito da un servizio chiamato API On-Prem Anthos. Per i cluster utente creati nella console, la gestione del ciclo di vita dei cluster viene abilitata al momento della creazione del cluster, oppure puoi abilitare questa funzionalità in un secondo momento per i cluster utente creati utilizzando bmctl. Se questa funzionalità non è abilitata, puoi gestire il ciclo di vita del cluster solo utilizzando bmctl sulla workstation di amministrazione.

Visualizza cluster registrati

Tutti i cluster del parco risorse vengono visualizzati nelle pagine Cluster Anthos e Cluster GKE nella console. Entrambi offrono una panoramica dell'intero parco risorse e, per Anthos clusters on bare metal, consentono di vedere quali cluster sono gestiti dall'API Anthos On-Prem.

Per visualizzare i cluster del parco risorse:

  1. Nella console, vai alla pagina Cluster Anthos.

    Vai a Cluster Anthos di Anthos

  2. Seleziona il progetto Google Cloud.

    • Se Anthos Bare Metal viene visualizzato nella colonna Tipo, il cluster è gestito dall'API Anthos On-Prem.

    • Se Esterna viene visualizzata nella colonna Tipo, il cluster non è gestito dall'API Anthos On-Prem.

Per visualizzare maggiori dettagli su un cluster, gli utenti devono accedere e autenticarsi nel cluster. A questo scopo, devi:

Configura l'autenticazione

Come descritto in precedenza, tutti i cluster del parco risorse vengono visualizzati negli elenchi di cluster GKE e Anthos nella console. Tuttavia, per visualizzare maggiori dettagli come nodi e carichi di lavoro (e per eseguire attività di gestione del ciclo di vita del cluster se la funzionalità è abilitata), gli utenti devono accedere al cluster e autenticarsi. A questo scopo, i tuoi cluster registrati devono essere configurati con uno dei seguenti metodi di autenticazione:

  • Identità Google: questa opzione consente agli utenti di accedere utilizzando la propria identità Google Cloud, ovvero l'indirizzo email associato al tuo account Google Cloud. Utilizza questa opzione se gli utenti hanno già accesso a Google Cloud con la propria identità Google. Se hai creato il cluster nella console, puoi accedere al cluster utilizzando la tua identità Google, ma dovrai configurare l'autenticazione per gli altri utenti.

    L'accesso con l'identità Google è l'approccio più semplice all'autenticazione nella console, quindi abbiamo descritto più avanti la procedura per configurarla in modo più dettagliato in Configurare l'autenticazione dell'identità Google.

  • OpenID Connect (OIDC): questa opzione consente agli utenti di accedere ai cluster dalla console utilizzando la propria identità da un provider di identità OIDC di terze parti come Okta o Microsoft AD FS. Ti consigliamo di utilizzare questa opzione se gli utenti hanno nomi utente, password e iscrizioni a gruppi di sicurezza esistenti del tuo provider. Nelle guide che seguono puoi scoprire come configurare l'autenticazione OIDC per i tuoi cluster:

  • Token di connessione: se le soluzioni fornite da Google precedenti non sono adatte alla tua organizzazione, puoi configurare l'autenticazione utilizzando un account di servizio Kubernetes e l'accesso con il token di connessione. Per i dettagli, consulta Configurare l'utilizzo di un token di connessione.

Concedi i ruoli richiesti

L'accesso alla console è controllato da Google Cloud IAM. Per gestire il ciclo di vita del cluster nella console, devi concedere alcuni ruoli IAM agli utenti che non sono proprietari del progetto:

  • Per consentire agli utenti di accedere alla console, devi concedere almeno i seguenti ruoli:

    • roles/container.viewer. Questo ruolo consente agli utenti di visualizzare la pagina Cluster GKE e altre risorse del container nella console. Per i dettagli sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, consulta i ruoli Kubernetes Engine nella documentazione IAM.

    • roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster all'esterno di Google Cloud nella console. Per i dettagli sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, consulta Ruoli di GKE Hub nella documentazione di IAM.

  • Per consentire agli utenti di gestire il ciclo di vita del cluster nella console, concedi il ruolo IAM roles/gkeonprem.admin. Il ruolo roles/gkeonprem.admin fornisce agli utenti l'accesso amministrativo all'API Anthos On-Prem, che la console utilizza per gestire il ciclo di vita del cluster. Per i dettagli sulle autorizzazioni incluse in questo ruolo, consulta Ruoli GKE On-Prem nella documentazione IAM.

I comandi seguenti mostrano come concedere i ruoli minimi necessari per gestire il ciclo di vita del cluster nella console:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

dove:

  • PROJECT_ID è il progetto host del parco risorse. Per i cluster creati utilizzando bmctl, questo è il progetto che hai configurato nella sezione gkeConnect del file di configurazione del cluster utente. Per i cluster creati nella console, è il progetto che hai scelto al momento della creazione del cluster.

  • MEMBER è l'indirizzo email dell'utente nel formato user:emailID, ad esempio: user:alice@example.com

Attiva la gestione del ciclo di vita del cluster nella console

I cluster utente creati nella console sono gestiti automaticamente dall'API Anthos On-Prem e consentono di eseguire le attività di gestione del ciclo di vita dei cluster nella console. Se vuoi abilitare questa funzionalità per i cluster utente creati utilizzando bmctl, segui i passaggi per configurare un cluster utente da gestire tramite l'API Anthos On-Prem. Quando la gestione del ciclo di vita dei cluster è abilitata, puoi aggiornare i cluster dalla console:

  • Aggiornare i cluster utente
  • Aggiungi o rimuovi pool di nodi sui cluster utente
  • Elimina cluster utente

Configurare l'autenticazione dell'identità Google

Per consentire agli utenti di accedere al cluster utilizzando la loro identità Google, devi configurare quanto segue:

  • Gli utenti devono avere ruoli specifici di Identity and Access Management (IAM) per poter visualizzare e interagire con i cluster nella console nell'elenco dei cluster GKE e nelle pagine relative all'elenco di cluster Anthos.

  • Gli utenti devono essere aggiunti ai criteri di controllo dell'accesso basati sui ruoli (RBAC) di Kubernetes necessari per l'accesso al gateway del cluster dell'API Kubernetes del cluster tramite l'agente di connessione.

Configura autorizzazione RBAC

Il server API Kubernetes di ogni cluster deve essere in grado di autorizzare le richieste che provengono dalla console. Per configurare l'autorizzazione, devi configurare i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes su ciascun cluster. Se hai creato il cluster nella console, l'API Anthos On-Prem aggiunge il tuo account utente come amministratore e crea criteri RBAC appropriati che ti concedono l'accesso amministrativo completo al cluster.

Interfaccia a riga di comando gcloud

Per applicare i criteri RBAC agli utenti, segui questi passaggi sulla tua workstation di amministrazione:

  1. Esegui questi comandi per accedere con il tuo Account Google e aggiornare i componenti:

    gcloud auth login
gcloud components update

  2. Genera e applica i criteri RBAC per il tuo cluster per utenti e account di servizio:

    gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

    Sostituisci quanto segue:

    • MEMBERSHIP_NAME: il nome utilizzato per rappresentare in modo univoco il cluster nel relativo parco risorse. In Anthos clusters on bare metal, il nome dell'appartenenza e il nome del cluster coincidono.
    • ROLE: il ruolo Kubernetes che vuoi concedere agli utenti nel cluster. Per concedere agli utenti l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi, specifica clusterrole/cluster-admin. Per limitare l'accesso, crea un ruolo personalizzato, ad esempio role/mynamespace/namespace-reader. Il ruolo personalizzato deve esistere già prima di eseguire il comando.
    • USERS: gli indirizzi email degli utenti (account utente o account di servizio) a cui vuoi concedere le autorizzazioni, come elenco separato da virgole. Ad esempio: --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
    • PROJECT_ID: l'ID del progetto host del parco risorse.
    • KUBECONFIG_PATH: il percorso file locale in cui viene archiviato il kubeconfig che contiene una voce per il cluster.

    • KUBECONFIG_CONTEXT: il contesto del cluster come appare nel file kubeconfig. Puoi ottenere il contesto attuale dalla riga di comando eseguendo kubectl config current-context. Indipendentemente dal fatto che tu stia utilizzando o meno il contesto attuale, assicurati che funzioni per accedere al cluster eseguendo un semplice comando come:

      kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

    Dopo aver eseguito gcloud container fleet memberships generate-gateway-rbac, viene visualizzato il seguente codice alla fine dell'output, che viene troncato per la leggibilità:

    Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
Writing RBAC policy for user: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.

    Si tratta del contesto per l'accesso al cluster tramite gateway di connessione.

    Per maggiori dettagli sul comando generate-gateway-rbac, consulta la guida di riferimento dell'interfaccia a riga di comando gcloud.

McBl

Per applicare i criteri RBAC agli utenti, segui questi passaggi sulla tua workstation di amministrazione:

  1. Aggiungi la sezione clusterSecurity.authorization al file di configurazione del cluster. Specifica l'indirizzo email e l'indirizzo email di altri utenti che devono amministrare il cluster. Ad esempio:

    ...
clusterSecurity:
  authorization:
    clusterAdmin:
      gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com]
...

  2. Aggiorna il cluster:

    bmctl update cluster \
    -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG

    Apporta le seguenti modifiche:

    • Sostituisci CLUSTER_NAME con il nome del cluster che vuoi aggiornare.
    • Se il cluster è un cluster con gestione automatica (ad es. amministratore o cluster autonomo), sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster. Se il cluster è un cluster utente, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster admin.

Informazioni dettagliate