Créer un cluster d'administrateur à l'aide de "gketl"

Créez un cluster d'administrateur pour Google Distributed Cloud (logiciel uniquement) pour VMware à l'aide de gkectl. Utilisez gkectl si vous devez gérer l'intégralité du cycle de vie de votre cluster d'administrateur en local dans votre environnement sur site pour répondre à des exigences strictes en termes de sécurité, de conformité ou d'isolation physique. Vous pouvez également créer un cluster d'administrateur à l'aide de Terraform ou de la consoleGoogle Cloud .

Avant de commencer

• Assurez-vous d'avoir configuré votre poste de travail administrateur et de pouvoir vous y connecter, comme décrit dans Créer un poste de travail administrateur.

• Assurez-vous que les fichiers de clé JSON des comptes de service se trouvent sur votre poste de travail administrateur.

• Consultez le document de planification des adresses IP. Assurez-vous de disposer de suffisamment d'adresses IP pour les trois nœuds du plan de contrôle et une adresse IP virtuelle du plan de contrôle. Si vous prévoyez de créer des clusters d'utilisateur kubeception, vous devez disposer de suffisamment d'adresses IP pour les nœuds de plan de contrôle de ces clusters d'utilisateur.

• Consultez la présentation de l'équilibrage de charge et examinez votre décision concernant le type d'équilibreur de charge que vous souhaitez utiliser. Pour les équilibreurs de charge manuels, vous devez configurer l'équilibreur de charge avant de créer votre cluster d'administrateur.

• Si vous utilisez gkectl pour créer le cluster d'administrateur, décidez si vous souhaitez utiliser un registre public ou privé pour les composants Google Distributed Cloud. Pour en savoir plus sur l'utilisation d'un registre Docker privé, consultez privateRegistry. Ni Terraform ni la console Google Cloud ne sont compatibles avec l'utilisation d'un registre Docker privé pour les composants système.

• Choisissez le type de système d'exploitation à exécuter sur vos nœuds de cluster d'administrateur.

• Si votre organisation exige que le trafic sortant passe par un serveur proxy, assurez-vous d'ajouter à la liste d'autorisation les API requises et l'adresse d'Artifact Registry.

• Dans les versions 1.29 et ultérieures, les vérifications préliminaires côté serveur sont activées par défaut. Les vérifications préliminaires côté serveur nécessitent des règles de pare-feu supplémentaires. Dans la section Règles de pare-feu pour les clusters d'administrateur, recherchez "Vérifications préaliminaires" et assurez-vous que toutes les règles de pare-feu requises sont configurées. Les vérifications préliminaires côté serveur sont exécutées sur le cluster d'amorçage au lieu d'être exécutées localement sur le poste de travail administrateur.

Présentation de la procédure

Voici les principales étapes à suivre pour créer un cluster d'administrateur :

1. Remplir vos fichiers de configuration Spécifiez les détails de votre nouveau fichier de configuration des identifiants d'administrateur et éventuellement un fichier de bloc d'adresses IP.

2. Importez des images d'OS dans vSphere et transférez des images de conteneurs vers le registre privé, le cas échéant. Exécutez gkectl prepare.

3. Créez un cluster d'administrateur. Utilisez gkectl pour créer un cluster d'administrateur comme spécifié dans vos fichiers de configuration terminés. Lorsque Google Distributed Cloud crée un cluster d'administrateur, il déploie un cluster Kubernetes in Docker (kind) pour héberger temporairement les contrôleurs Kubernetes nécessaires à la création du cluster d'administrateur. Ce cluster temporaire est appelé cluster d'amorçage. Les clusters d'utilisateur sont créés et mis à niveau par leur administrateur de gestion sans utiliser de cluster d'amorçage.

4. Vérifiez que votre cluster d'administrateur est en cours d'exécution. Utilisez kubectl pour afficher les nœuds de votre cluster.

À la fin de cette procédure, vous disposerez d'un cluster d'administrateur en cours d'exécution que vous pourrez utiliser pour créer et gérer des clusters d'utilisateur.

Si vous utilisez VPC Service Controls, des erreurs peuvent s'afficher lorsque vous exécutez certaines commandes gkectl, telles que "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Pour éviter ces erreurs, ajoutez le paramètre --skip-validation-gcp à vos commandes.

Remplir le fichier de configuration

• Assurez-vous que votre poste de travail administrateur dispose de la version requise de gkectl. En règle générale, vous utilisez la même version de gkectl que celle qui sera utilisée lors de la création du cluster. Vous spécifiez la version du cluster dans le champ gkeOnPremVersion du fichier de configuration du cluster. Les règles de version suivantes sont appliquées lors de la création du cluster :

  • La version mineure gkectl ne peut pas être inférieure à celle du cluster. Par exemple, il n'est pas autorisé de créer un cluster 1.30 à l'aide de la version 1.29 de gkectl. Les versions de correctif n'ont pas d'importance. Par exemple, vous pouvez utiliser la version 1.29.0-gke.1456 de gkectl pour créer un cluster avec une version de correctif supérieure, telle que 1.29.1000-gke.94.

  • La version mineure gkectl ne peut pas être supérieure de plus de deux versions mineures à la version du cluster. Par exemple, si vous créez un cluster 1.28, la version gkectl peut être 1.29 ou 1.30. Toutefois, vous ne pouvez pas utiliser la version 1.31 de gkectl, car elle est trois versions mineures plus récente que la version du cluster.

  Si nécessaire, consultez Télécharger gkectl pour obtenir une version compatible de gkectl.

Si vous avez utilisé gkeadm pour créer votre poste de travail administrateur, il a généré un fichier de configuration nommé admin-cluster.yaml.

Si vous n'avez pas utilisé gkeadm pour créer votre poste de travail administrateur, générez admin-cluster.yaml en exécutant la commande suivante sur votre poste de travail administrateur :

gkectl create-config admin

Ce fichier de configuration vous permet de créer votre cluster d'administrateur.

Familiarisez-vous avec le fichier de configuration en analysant le fichier de configuration du cluster d'administrateur. Nous vous recommandons de conserver ce document ouvert dans un nouvel onglet ou dans une autre fenêtre, car vous en aurez besoin pour réaliser les étapes suivantes.

name

Si vous souhaitez spécifier un nom pour votre cluster d'administrateur, renseignez le champ name.

bundlePath

Le bundle est un fichier compressé contenant les composants du cluster. Il est inclus dans le poste de travail d'administrateur. Ce champ est déjà renseigné.

vCenter

La plupart des champs de cette section sont déjà renseignés avec les valeurs que vous avez saisies lors de la création de votre poste de travail administrateur.

enableAdvancedCluster

Dans la version 1.31, si vous souhaitez activer la fonctionnalité de cluster avancée, définissez enableAdvancedCluster sur true.

Notez les différences suivantes entre les versions :

• Dans la version 1.31, la fonctionnalité de cluster avancé est en version preview :

  • Vous ne pouvez activer le cluster avancé que lors de la création de nouveaux clusters 1.31.

  • Une fois le cluster avancé activé, vous ne pourrez pas le mettre à niveau vers la version 1.32. N'activez le cluster avancé que dans un environnement de test.

• Dans la version 1.32, la fonctionnalité de cluster avancé est en disponibilité générale.

  • Par défaut, les clusters d'administrateur sont créés en tant que clusters avancés. Vous devez définir explicitement enableAdvancedCluster sur false si vous souhaitez créer un cluster non avancé.

  • Les mises à niveau de cluster sont acceptées pour les clusters sur lesquels la fonctionnalité de clusters avancés est activée.

• Dans la version 1.33 et les suivantes, tous les clusters sont créés en tant que clusters avancés. Si vous définissez enableAdvancedCluster sur false, la création du cluster échoue.

network

Remplissez les sections network.controlPlaneIPBlock et network.hostConfig. Définissez également adminMaster.replicas sur 3.

Les champs network.podCIDR et network.serviceCIDR sont préremplis avec des valeurs que vous pouvez laisser inchangées, sauf si elles entrent en conflit avec des adresses déjà utilisées sur votre réseau. Kubernetes utilise ces plages pour attribuer des adresses IP aux pods et aux services de votre cluster.

Renseignez les autres champs selon les besoins dans la section réseau du fichier de configuration.

loadBalancer

Réservez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'administration. Indiquez votre adresse IP virtuelle comme valeur pour loadBalancer.vips.controlPlaneVIP.

Pour en savoir plus, consultez la page Adresses IP virtuelles dans le sous-réseau du cluster d'administrateur.

Choisissez le type d'équilibrage de charge que vous souhaitez utiliser. Vous disposez des options suivantes :

• Équilibrage de charge groupé MetalLB. Définissez loadBalancer.kind sur "MetalLB".

• Équilibrage de charge manuel. Définissez loadBalancer.kind sur "ManualLB", puis supprimez la section manualLB.

Pour en savoir plus sur les options d'équilibrage de charge, consultez la page Présentation de l'équilibrage de charge.

antiAffinityGroups

Définissez antiAffinityGroups.enabled sur true ou false en fonction de votre préférence.

Utilisez ce champ pour indiquer si vous souhaitez que les clusters Google Distributed Cloud créent des règles d'anti-affinité VMware DRS (Distributed Resource Scheduler) pour les nœuds de votre cluster d'administrateur. Ceux-ci sont ainsi répartis sur au moins trois hôtes physiques dans votre centre de données.

adminMaster

Si vous souhaitez spécifier le processeur et la mémoire pour les nœuds de plan de contrôle du cluster d'administrateur, remplissez les champs cpus et memoryMB dans la section adminMaster.

Les clusters d'administrateur doivent comporter trois nœuds de plan de contrôle. Définissez le champ replicas de la section adminMaster sur 3.

proxy

Si le réseau qui contiendra vos nœuds de cluster d'administrateur se trouve derrière un serveur proxy, remplissez la section proxy.

privateRegistry

Décidez où vous souhaitez conserver les images de conteneur pour les composants Google Distributed Cloud. Vous disposez des options suivantes :

• Artifact Registry

• Votre propre registre Docker privé.

  Si vous souhaitez utiliser votre propre registre privé, remplissez la section privateRegistry.

Pour en savoir plus sur l'utilisation d'un registre privé, y compris sur les différences entre les clusters normaux et les clusters avancés, consultez Configurer un registre de conteneurs privé.

componentAccessServiceAccountKeyPath

Google Distributed Cloud utilise votre compte de service d'accès aux composants pour télécharger les composants de cluster à partir d'Artifact Registry. Ce champ contient le chemin d'accès à un fichier de clé JSON pour votre compte de service d'accès au composant.

Ce champ est déjà renseigné.

gkeConnect

Enregistrez votre cluster d'administrateur dans un parc Google Cloud en remplissant la section gkeConnect. Si vous incluez les sections stackdriver et cloudAuditLogging dans le fichier de configuration, l'ID de gkeConnect.projectID doit être identique à celui défini dans stackdriver.projectID et cloudAuditLogging.projectID. Si les ID de projet ne sont pas identiques, la création du cluster échoue.

Dans la version 1.28 et les versions ultérieures, vous pouvez éventuellement spécifier une région dans laquelle les services Fleet et Connect s'exécutent dans gkeConnect.location. Si vous n'incluez pas ce champ, le cluster utilise les instances globales de ces services.

Si vous incluez gkeConnect.location, la région que vous spécifiez doit être identique à celle configurée dans cloudAuditLogging.clusterLocation, stackdriver.clusterLocation et gkeOnPremAPI.location. Si les régions ne sont pas identiques, la création du cluster échoue.

gkeOnPremAPI

Si l'API GKE On-Prem est activée dans votre projetGoogle Cloud , tous les clusters du projet sont automatiquement enregistrés dans l'API GKE On-Prem dans la région configurée dans stackdriver.clusterLocation. La région gkeOnPremAPI.location doit être identique à celle spécifiée dans cloudAuditLogging.clusterLocation, gkeConnect.location et stackdriver.clusterLocation. Si les régions ne sont pas identiques, la création du cluster échoue.

• Si vous souhaitez enregistrer tous les clusters du projet dans l'API GKE On-Prem, veillez à suivre les étapes de la section Avant de commencer pour activer et utiliser l'API GKE On-Prem dans le projet.

• Si vous ne souhaitez pas enregistrer le cluster dans l'API GKE On-Prem, incluez cette section et définissez gkeOnPremAPI.enabled sur false. Si vous ne souhaitez enregistrer aucun cluster dans le projet, désactivez gkeonprem.googleapis.com (nom de service de l'API GKE On-Prem) dans le projet. Pour obtenir des instructions, consultez la section Désactiver des services.

stackdriver

Si vous souhaitez activer Cloud Logging et Cloud Monitoring pour votre cluster, renseignez la section stackdriver.

Cette section est obligatoire par défaut. Autrement dit, si vous ne remplissez pas cette section, vous devez inclure l'option --skip-validation-stackdriver lorsque vous exécutez gkectl create admin.

Notez les exigences suivantes :

• Si vous activez le cluster avancé, vous devez spécifier le même chemin d'accès dans cloudAuditLogging.serviceAccountKeyPath et stackdriver.serviceAccountKeyPath.

• L'ID dans stackdriver.projectID doit être identique à celui dans gkeConnect.projectID et cloudAuditLogging.projectID.

• La région Google Cloud définie dans stackdriver.clusterLocation doit être identique à celle définie dans cloudAuditLogging.clusterLocation et gkeConnect.location. En outre, si gkeOnPremAPI.enabled est défini sur true, la même région doit être définie dans gkeOnPremAPI.location.

Si les ID de projet et les régions ne sont pas identiques, la création du cluster échoue.

cloudAuditLogging

Si vous souhaitez intégrer les journaux d'audit du serveur d'API Kubernetes de votre cluster avec les journaux d'audit Cloud, remplissez la section cloudAuditLogging.

Notez les exigences suivantes :

• Si vous activez le cluster avancé, vous devez spécifier le même chemin d'accès dans cloudAuditLogging.serviceAccountKeyPath et stackdriver.serviceAccountKeyPath.

• L'ID dans cloudAuditLogging.projectID doit être identique à celui dans gkeConnect.projectID et stackdriver.projectID.

• La région Google Cloud définie dans cloudAuditLogging.clusterLocation doit être la même que celle définie dans stackdriver.clusterLocation et gkeConnect.location (si le champ est inclus dans votre fichier de configuration). En outre, si gkeOnPremAPI.enabled est défini sur true, la même région doit être définie dans gkeOnPremAPI.location.

Si les ID de projet et les régions ne sont pas identiques, la création du cluster échoue.

clusterBackup

Si vous souhaitez activer la sauvegarde du cluster d'administrateur, définissez clusterBackup.datastore sur le datastore vSphere dans lequel vous souhaitez enregistrer les sauvegardes de cluster.

Si vous activez le cluster avancé, supprimez cette section. La sauvegarde du cluster d'administrateur dans un datastore vSphere n'est pas prise en charge.

autoRepair

Si vous souhaitez activer la réparation automatique des nœuds pour votre cluster d'administrateur, définissez autoRepair.enabled sur true.

secretsEncryption

Si vous souhaitez activer le chiffrement permanent des secrets, remplissez la section secretsEncryption.

Si vous activez le cluster avancé, définissez secretsEncryption.enabled sur false. Le chiffrement des secrets toujours activé n'est pas pris en charge.

osImageType

Choisissez le type d'image d'OS que vous souhaitez utiliser pour les nœuds de cluster d'administrateur et renseignez la section osImageType en conséquence.

Si vous activez le cluster avancé, définissez osImageType sur ubuntu_cgroupv2 ou ubuntu_containerd.

Exemple de fichiers de configuration préremplis

Voici un exemple de fichier de configuration de cluster d'administrateur renseigné. La configuration active certaines des fonctionnalités disponibles, mais pas toutes.

vc-01-admin-cluster.yaml

apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.28.0-gke.1-full.tgz"
vCenter:
  address: "vc01.example"
  datacenter: "vc-01"
  cluster: "vc01-workloads-1"
  resourcePool: "vc-01-pool-1"
  datastore: "vc01-datastore-1"
  caCertPath: "/usr/local/google/home/me/certs/vc01-cert.pem""
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.1"
    - "198.51.100.1"
    ntpServers:
    - "216.239.35.4"
  serviceCIDR: "10.96.232.0/24"
  podCIDR: "192.168.0.0/16"
  vCenter:
    networkName: "vc01-net-1"
  controlPlaneIPBlock:
    netmask: "255.255.248.0"
    gateway: "21.0.143.254"
    ips:
    - ip: "21.0.140.226"
      hostname: "admin-cp-vm-1"
    - ip: "21.0.141.48"
      hostname: "admin-cp-vm-2"
    - ip: "21.0.141.65"
      hostname: "admin-cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.59"
  kind: "MetalLB"
antiAffinityGroups:
  enabled: true
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3
componentAccessServiceAccountKeyPath: "sa-key.json"
gkeConnect:
  projectID: "my-project-123"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
  disableVsphereResourceMetrics: false
clusterBackup:
  datastore: "vc-01-datastore-bu"
autoRepair:
  enabled: true
osImageType: "ubuntu_containerd"

Valider votre fichier de configuration

Après avoir rempli le fichier de configuration du cluster d'administrateur, exécutez gkectl check-config pour vérifier que le fichier est valide :

gkectl check-config --config ADMIN_CLUSTER_CONFIG

Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès de votre fichier de configuration de cluster d'administrateur.

Si la commande renvoie des messages d'échec, corrigez les problèmes et validez à nouveau le fichier.

Si vous souhaitez ignorer les validations les plus longues, transmettez l'option --fast. Pour ignorer des validations individuelles, utilisez les options --skip-validation-yyy. Pour en savoir plus sur la commande check-config, consultez la page Exécuter des vérifications préliminaires.

Obtenir des images de l'OS

Exécutez gkectl prepare pour initialiser votre environnement vSphere :

gkectl prepare --config ADMIN_CLUSTER_CONFIG

La commande gkectl prepare exécute les tâches préparatoires suivantes :

• Importe les images d'OS vers vSphere et les marque comme modèles de VM.

• Transfère les images de conteneurs vers votre registre, si vous utilisez un registre Docker privé.

• Valide, éventuellement, des attestations de version des images de conteneur, vérifiant ainsi que les images ont été conçues et signées par Google, et sont prêtes pour le déploiement.

Si vous avez configuré votre bundlePath pour utiliser un bundle complet, gkectl prepare utilise les images de l'OS et du conteneur incluses dans le bundle, ce qui évite de les télécharger à partir de réseaux externes. Cette option est recommandée pour les environnements situés derrière un proxy lent ou avec un accès limité à Internet. Pour en savoir plus, consultez À propos des bundles Google Distributed Cloud.

Remarque : Si vous utilisez des noms DNS internes ou si votre station de travail ne peut pas accéder aux adresses DNS publiques de Google (8.8.8.8 ou 8.8.4.4), vous devez spécifier votre serveur de noms interne dans /etc/resolv.conf.

Créez le cluster d'administrateur :

Créez le cluster d'administrateur :

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Si vous utilisez VPC Service Controls, des erreurs peuvent s'afficher lorsque vous exécutez certaines commandes gkectl, telles que "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Pour éviter ces erreurs, ajoutez le paramètre --skip-validation-gcp à vos commandes.

Reprendre la création du cluster d'administrateur après un échec

Si la création du cluster d'administrateur échoue ou est annulée, vous pouvez exécuter à nouveau la commande create :

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Localiser le fichier kubeconfig du cluster d'administrateur

La commande gkectl create admin crée un fichier kubeconfig nommé kubeconfig dans le répertoire actuel. Vous aurez besoin de ce fichier kubeconfig ultérieurement pour interagir avec votre cluster d'administrateur.

Le fichier kubeconfig contient le nom de votre cluster d'administrateur. Pour afficher le nom du cluster, vous pouvez exécuter la commande suivante :

kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Le résultat affiche le nom du cluster. Exemple :

NAME
gke-admin-tqk8x

Si vous le souhaitez, vous pouvez modifier le nom et l'emplacement de votre fichier kubeconfig.

Gérer le fichier checkpoint.yaml

Cette section ne s'applique qu'aux clusters d'administrateur non HA. Le fichier checkpoint.yaml n'est pas utilisé pour créer des clusters d'administrateur à haute disponibilité.

Lorsque vous avez exécuté la commande gkectl create admin pour créer le cluster d'administrateur, elle a créé un fichier de point de contrôle dans le même dossier de datastore que le disque de données du cluster d'administrateur. Par défaut, ce fichier est nommé DATA_DISK_NAME‑checkpoint.yaml. Si la longueur de DATA_DISK_NAME est supérieure ou égale à 245 caractères, le nom est DATA_DISK_NAME.yaml en raison de la limite de longueur des noms de fichier vSphere.

Ce fichier contient l'état et les identifiants du cluster d'administrateur, et il est utilisé pour les mises à niveau ultérieures. Ne supprimez pas ce fichier, sauf si vous suivez la procédure de suppression d'un cluster d'administrateur.

Si vous avez activé le chiffrement de VM dans votre instance de vCenter Server, vous devez disposer du droit Opérations de chiffrement accès direct avant de créer ou de mettre à niveau votre cluster d'administrateur. Sinon, le point de contrôle ne sera pas importé. Si vous ne pouvez pas obtenir ce privilège, vous pouvez désactiver l'importation du fichier de point de contrôle à l'aide de l'indicateur masqué --disable-checkpoint lorsque vous exécutez une commande appropriée.

Le fichier checkpoint.yaml est automatiquement mis à jour lorsque vous exécutez la commande gkectl upgrade admin ou lorsque vous exécutez une commande gkectl update qui affecte le cluster d'administrateur.

Vérifier que votre cluster d'administrateur est en cours d'exécution

Vérifiez que votre cluster d'administrateur est en cours d'exécution :

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'administrateur.

Le résultat affiche les nœuds du cluster d'administrateur. Exemple :

admin-cp-vm-1   Ready    control-plane,master   ...
admin-cp-vm-2   Ready    control-plane,master   ...
admin-cp-vm-3   Ready    control-plane,master   ...

Sauvegarder des fichiers

Nous vous recommandons de sauvegarder le fichier kubeconfig de votre cluster d'administrateur. Autrement dit, copiez le fichier kubeconfig de votre poste de travail administrateur vers un autre emplacement. Ainsi, si vous perdez l'accès au poste de travail administrateur ou si le fichier kubeconfig de votre poste de travail administrateur est supprimé par erreur, vous avez toujours accès au cluster d'administrateur.

Nous vous recommandons également de sauvegarder la clé SSH privée de votre cluster d'administrateur. Si vous perdez l'accès au cluster d'administrateur, vous pouvez toujours utiliser SSH pour vous connecter aux nœuds du cluster d'administrateur. Cela vous permettra de résoudre et d'examiner les problèmes de connectivité au cluster d'administrateur.

Extrayez la clé SSH du cluster d'administrateur dans un fichier nommé admin-cluster-ssh-key :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \
    -o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key

Vous pouvez désormais sauvegarder admin-cluster-ssh-key à l'emplacement de votre choix.

Stratégies RBAC

Lorsque vous remplissez la section gkeConnect dans le fichier de configuration de votre cluster d'administrateur, le cluster est enregistré dans votre parc lors de sa création ou de sa mise à jour. Pour activer la fonctionnalité de gestion du parc, Google Cloud déploie l'agent Connect et crée un compte de service Google qui représente le projet auprès duquel le cluster est enregistré. L'agent Connect établit une connexion avec le compte de service pour gérer les requêtes adressées au serveur d'API Kubernetes du cluster. Cela vous permet ainsi d'accéder aux fonctionnalités de gestion des clusters et des charges de travail dans Google Cloud, y compris l'accès à la consoleGoogle Cloud , qui vous permet d'interagir avec votre cluster.

Le serveur d'API Kubernetes du cluster d'administrateur doit être en mesure d'autoriser les requêtes de l'agent Connect. Pour ce faire, les stratégies de contrôle d'accès basé sur les rôles (RBAC) suivantes sont configurées sur le compte de service :

• Une règle d'emprunt d'identité qui autorise l'agent Connect à envoyer des requêtes au serveur d'API Kubernetes au nom du compte de service.

• Une stratégie d'autorisation qui spécifie les opérations autorisées sur d'autres ressources Kubernetes.

Le compte de service et les stratégies RBAC sont nécessaires pour gérer le cycle de vie de vos clusters d'utilisateur dans la console Google Cloud .