Gérer des clusters depuis la console Google Cloud

Ce document explique comment gérer GKE sur une solution Bare Metal dans la console Google Cloud. Cela inclut la gestion de base, comme la possibilité de se connecter aux clusters et d'afficher leurs charges de travail, ainsi que l'activation de la gestion du cycle de vie des clusters afin de pouvoir les mettre à niveau, les mettre à jour et les supprimer.

Membres du parc et console

Tous les clusters GKE sur Bare Metal doivent être membres d'un parc, un moyen unifié d'afficher et de gérer plusieurs clusters ainsi que leurs charges de travail. Chaque parc de clusters est associé à un projet hôte de parc.

Dans GKE sur Bare Metal, un cluster d'utilisateur est enregistré dans un parc au moment de sa création:

  • Lorsque vous créez un cluster à l'aide de bmctl, vous spécifiez le projet hôte de votre parc dans la section gkeConnect du fichier de configuration du cluster. GKE sur Bare Metal utilise ces informations pour enregistrer votre cluster dans le projet de parc spécifié.

  • Lorsque vous créez un cluster d'utilisateur dans la console, celui-ci devient automatiquement un membre du parc dans le projet sélectionné dans la console.

Les membres de votre parc en dehors de Google Cloud, tels que GKE sur Bare Metal, sont affichés dans la console du projet hôte de votre parc, avec d'autres clusters de parc tels que GKE sur Google Cloud. La mesure dans laquelle vous pouvez gérer GKE sur une solution Bare Metal à partir de la console dépend des éléments suivants:

  • Si vous avez configuré l'authentification, vous pouvez vous connecter à vos clusters et afficher leurs charges de travail et d'autres détails.

  • Si vous avez activé la gestion du cycle de vie des clusters, vous pouvez également mettre à niveau, mettre à jour ou supprimer des clusters d'utilisateur à l'aide de la console. Pour ce faire, le cluster doit être géré par un service appelé API GKE On-Prem. Pour les clusters d'utilisateur créés dans la console, la gestion du cycle de vie du cluster est activée au moment de la création du cluster. Vous pouvez également activer cette fonctionnalité ultérieurement pour les clusters d'utilisateur créés à l'aide de bmctl. Si cette fonctionnalité n'est pas activée, vous ne pouvez gérer le cycle de vie d'un cluster qu'à l'aide de bmctl sur votre poste de travail administrateur.

Afficher les clusters enregistrés

Tous les clusters de votre parc affichent les pages Clusters GKE dans la console. Cela vous donne à la fois un aperçu de l'ensemble de votre parc et, pour GKE sur Bare Metal, vous permet de voir quels clusters sont gérés par l'API GKE On-Prem.

Pour afficher les clusters de votre parc:

  1. Dans la console, accédez à la page de présentation des clusters Google Kubernetes Engine.

    Accéder aux clusters GKE

  2. Sélectionnez le projet Google Cloud.

    • Si Bare Metal s'affiche dans la colonne Type, le cluster est géré par l'API GKE On-Prem.

    • Si Externe s'affiche dans la colonne Type, cela signifie que le cluster n'est pas géré par l'API GKE On-Prem.

Pour afficher plus de détails sur un cluster, vous devez vous connecter et vous authentifier auprès du cluster. Pour ce faire, procédez comme suit:

Configurer l'authentification

Comme décrit précédemment, tous les clusters de parc apparaissent sur la page des clusters GKE de la console. Toutefois, pour afficher plus de détails tels que les nœuds et les charges de travail (et pour effectuer des tâches de gestion du cycle de vie du cluster si la fonctionnalité est activée), vous devez vous connecter au cluster et vous authentifier. Pour ce faire, vos clusters enregistrés doivent être configurés avec l'une des méthodes d'authentification suivantes:

  • Identité Google: cette option vous permet de vous connecter à l'aide de votre identité Google Cloud, qui est l'adresse e-mail associée à votre compte Google Cloud. Utilisez cette option si les utilisateurs ont déjà accès à Google Cloud avec leur identité Google. Si vous avez créé le cluster dans la console, vous pouvez vous y connecter à l'aide de votre identité Google, mais vous devrez configurer l'authentification pour les autres utilisateurs.

    La connexion avec l'identité Google est l'approche la plus simple pour l'authentification dans la console. Nous avons donc décrit la configuration plus en détail dans Configurer l'authentification de l'identité Google.

  • OpenID Connect (OIDC): cette option vous permet de vous connecter aux clusters depuis la console en utilisant leur identité depuis un fournisseur d'identité OIDC tiers tel que Okta ou Microsoft AD FS. Vous pouvez utiliser cette option si vos utilisateurs disposent déjà de noms d'utilisateur, de mots de passe et d'adhésions à des groupes de sécurité auprès de votre fournisseur. Vous pouvez découvrir comment configurer l'authentification OIDC tierce pour vos clusters dans les guides suivants:

  • Jeton de support: si les solutions précédentes fournies par Google ne sont pas adaptées à votre organisation, vous pouvez configurer l'authentification à l'aide d'un compte de service Kubernetes et de son jeton de support pour vous connecter. Pour en savoir plus, consultez la section Configurer à l'aide d'un jeton de support.

Attribuer les rôles requis

L'accès à la console est contrôlé par Google Cloud IAM. Pour gérer le cycle de vie du cluster dans la console, vous devez attribuer des rôles IAM aux utilisateurs qui ne sont pas propriétaires de projet:

  • Pour permettre aux utilisateurs d'accéder à la console, vous devez au minimum leur attribuer les rôles suivants:

    • roles/container.viewer. Ce rôle permet aux utilisateurs d'afficher la page "Clusters GKE" et les autres ressources de conteneur dans la console. Pour en savoir plus sur les autorisations incluses dans ce rôle ou pour attribuer un rôle doté d'autorisations de lecture et d'écriture, consultez la section Rôles Kubernetes Engine dans la documentation IAM.

    • roles/gkehub.viewer. Ce rôle permet aux utilisateurs d'afficher les clusters en dehors de Google Cloud dans la console. Pour en savoir plus sur les autorisations incluses dans ce rôle ou pour attribuer un rôle doté d'autorisations de lecture et d'écriture, consultez la section Rôles GKE Hub dans la documentation IAM.

  • Pour permettre aux utilisateurs de gérer le cycle de vie du cluster dans la console, accordez le rôle IAM roles/gkeonprem.admin. Le rôle roles/gkeonprem.admin accorde aux utilisateurs un accès administrateur à l'API GKE On-Prem, que la console utilise pour gérer le cycle de vie du cluster. Pour en savoir plus sur les autorisations incluses dans ce rôle, consultez la section Rôles GKE On-Prem dans la documentation IAM.

Les commandes suivantes montrent comment attribuer les rôles minimaux nécessaires pour gérer le cycle de vie du cluster dans la 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

où :

  • PROJECT_ID est le projet hôte du parc. Pour les clusters créés à l'aide de bmctl, il s'agit du projet que vous avez configuré dans la section gkeConnect du fichier de configuration du cluster d'utilisateur. Pour les clusters créés dans la console, il s'agit du projet que vous avez choisi lors de la création du cluster.

  • MEMBER est l'adresse e-mail de l'utilisateur au format user:emailID, par exemple: user:alice@example.com.

Activer la gestion du cycle de vie des clusters dans la console

Les clusters d'utilisateur créés dans la console sont automatiquement gérés par l'API GKE On-Prem et vous permettent d'effectuer des tâches de gestion du cycle de vie des clusters dans la console. Si vous souhaitez activer cette fonctionnalité pour les clusters d'utilisateur créés à l'aide de bmctl, suivez la procédure décrite dans la section Configurer un cluster d'utilisateur à gérer par l'API GKE On-Prem. Lorsque la gestion du cycle de vie des clusters est activée, vous pouvez les mettre à jour depuis la console:

  • Mettre à jour des clusters d'utilisateurs
  • Ajouter ou supprimer des pools de nœuds sur des clusters d'utilisateur
  • Supprimer des clusters d'utilisateur

Configurer l'authentification de l'identité Google

Pour permettre aux utilisateurs de se connecter au cluster à l'aide de leur identité Google, vous devez configurer les éléments suivants:

  • Les utilisateurs ont besoin de rôles IAM (Identity and Access Management) spécifiques pour pouvoir afficher les clusters et interagir avec ceux-ci dans la console, sur la page Clusters GKE.

  • Les utilisateurs doivent être ajoutés aux stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes dont la passerelle Connect a besoin pour accéder au serveur d'API Kubernetes du cluster lors de l'utilisation de l'agent Connect.

Configurer l'autorisation RBAC

Le serveur d'API Kubernetes de chaque cluster doit être en mesure d'autoriser les requêtes provenant de la console. Pour configurer l'autorisation, vous devez configurer des stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes sur chaque cluster. Si vous avez créé le cluster dans la console, l'API GKE On-Prem ajoute votre compte utilisateur en tant qu'administrateur et crée les stratégies RBAC appropriées qui vous accordent un accès administrateur complet au cluster.

gcloud CLI

Pour appliquer les stratégies RBAC aux utilisateurs, procédez comme suit sur votre poste de travail administrateur:

  1. Exécutez les commandes suivantes pour vous connecter avec votre compte Google et mettre à jour les composants:

    gcloud auth login
gcloud components update

  2. Générez et appliquez les stratégies RBAC à votre cluster pour les utilisateurs et les comptes de service:

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

    Remplacez les éléments suivants :

    • MEMBERSHIP_NAME: nom utilisé pour représenter de manière unique le cluster dans son parc. Dans GKE sur Bare Metal, le nom de l'appartenance et le nom du cluster sont identiques.
    • ROLE: rôle Kubernetes que vous souhaitez attribuer aux utilisateurs du cluster. Pour accorder aux utilisateurs un accès complet à toutes les ressources du cluster dans tous les espaces de noms, spécifiez clusterrole/cluster-admin. Pour restreindre l'accès, créez un rôle personnalisé, par exemple: role/mynamespace/namespace-reader. Le rôle personnalisé doit déjà exister avant que vous puissiez exécuter la commande.
    • USERS : adresses e-mail des utilisateurs (comptes utilisateur ou comptes de service) auxquels vous souhaitez accorder les autorisations, sous la forme d'une liste d'éléments séparés par une virgule. Exemple : --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
    • PROJECT_ID: ID du projet hôte du parc.
    • KUBECONFIG_PATH: chemin d'accès local au fichier kubeconfig contenant une entrée pour le cluster.

    • KUBECONFIG_CONTEXT : contexte du cluster tel qu'il apparaît dans le fichier kubeconfig. Vous pouvez obtenir le contexte actuel à partir de la ligne de commande en exécutant la commande kubectl config current-context. Que vous utilisiez le contexte actuel ou non, assurez-vous qu'il fonctionne pour l'accès au cluster en exécutant une commande simple telle que la suivante :

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

    Après avoir exécuté gcloud container fleet memberships generate-gateway-rbac, un résultat semblable à ce qui suit s'affiche à la fin du résultat, qui est tronqué pour des raisons de lisibilité:

    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.

    Il s'agit du contexte permettant d'accéder au cluster via la passerelle de connexion.

    Pour en savoir plus sur la commande generate-gateway-rbac, consultez le guide de référence de gcloud CLI.

bmctl

Pour appliquer les stratégies RBAC aux utilisateurs, procédez comme suit sur votre poste de travail administrateur:

  1. Ajoutez la section clusterSecurity.authorization au fichier de configuration de votre cluster. Spécifiez votre adresse e-mail et celle des autres utilisateurs devant administrer le cluster. Exemple :

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

  2. Mettez à jour le cluster :

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

    Apportez les modifications suivantes :

    • Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.
    • Si le cluster est un cluster autogéré (tel qu'un cluster d'administrateur ou autonome), remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster. Si le cluster est un cluster d'utilisateur, remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster admin.

Informations complémentaires