Les clusters Anthos sur bare metal s'appellent désormais Google Distributed Cloud (logiciel uniquement) pour bare metal. Pour en savoir plus, consultez la présentation du produit.

Cette page a été traduite par l'API Cloud Translation.

Créer des clusters d'utilisateur

Dans Google Distributed Cloud, les clusters d'utilisateur exécutent vos charges de travail. Dans une architecture multicluster, les clusters d'utilisateur sont créés et gérés par un cluster d'administrateur.

Une fois que vous avez créé un cluster d'administrateur, l'appel de la commande bmctl create config crée un fichier YAML que vous pouvez modifier pour définir votre cluster d'utilisateur. Pour appliquer la configuration et créer le cluster d'utilisateur, utilisez la commande bmctl create cluster. Les vérifications préliminaires s'appliquent aux clusters d'utilisateur créés à l'aide de la commande bmctl create cluster.

Le fait de conserver des charges de travail hors du cluster d'administrateur protège les données d'administration sensibles, telles que les clés SSH stockées dans le cluster d'administrateur, de celles qui ne doivent pas accéder à ces informations. En outre, séparer les clusters d'utilisateur les uns des autres assure une sécurité générale satisfaisante à vos charges de travail.

Prérequis

La dernière version de bmctl est téléchargée (gs://anthos-baremetal-release/bmctl/1.29.100-gke.251/linux-amd64/bmctl) à partir de Cloud Storage.
Un cluster d'administrateur opérationnel ayant accès au serveur d'API du cluster (controlPlaneVIP)
Les nœuds du cluster d'administrateur disposent d'une connectivité réseau à tous les nœuds du cluster d'utilisateur cible.
Le poste de travail qui exécute bmctl dispose d'une connectivité réseau à tous les nœuds dans les clusters d'utilisateurs cibles.
Le poste de travail administrateur peut établir une connexion SSH avec chacun des nœuds du cluster d'utilisateur.
Le compte de service "connect-register" est configuré sur le cluster d'administrateur pour une utilisation avec Connect.

Activer SELinux

Si vous souhaitez activer SELinux pour sécuriser vos conteneurs, vous devez vous assurer que SELinux est activé en mode Enforced sur toutes vos machines hôtes. À partir de la version 1.9.0 de Google Distributed Cloud ou version ultérieure, vous pouvez activer ou désactiver SELinux avant ou après la création ou la mise à niveau du cluster. SELinux est activé par défaut sur Red Hat Enterprise Linux (RHEL). Si SELinux est désactivé sur vos machines hôtes ou si vous avez un doute, consultez la section Sécuriser vos conteneurs à l'aide de SELinux pour savoir comment l'activer.

Google Distributed Cloud n'est compatible avec SELinux que dans les systèmes RHEL.

Créer un fichier de configuration de cluster d'utilisateur

Le fichier de configuration permettant de créer un cluster d'utilisateur est presque identique à celui utilisé pour créer un cluster d'administrateur. La seule différence est que vous supprimez la section de configuration des identifiants locaux pour faire de cette configuration une collection valide de ressources Kubernetes. La section de configuration se trouve en haut du fichier, dans la section bmctl configuration variables. Pour obtenir des exemples de configurations de cluster d'utilisateur, consultez la section Clusters d'utilisateur dans les exemples de configuration de cluster.

Par défaut, les clusters d'utilisateur héritent leurs identifiants du cluster d'administrateur qui les gère. Vous pouvez remplacer chacun ou la totalité de ces identifiants.

Créez un fichier de configuration de cluster d'utilisateur à l'aide de la commande bmctl create config:
```
bmctl create config -c USER_CLUSTER_NAME
```
Par exemple, exécutez la commande suivante pour créer un fichier de configuration pour un cluster d'utilisateur appelé user1:
```
bmctl create config -c user1
```
Le fichier est écrit dans bmctl-workspace/user1/user1.yaml. Le chemin générique vers le fichier est bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml.
Apportez les modifications suivantes dans le fichier de configuration:
- Supprimez de la configuration les chemins d'accès au fichier d'identifiants locaux :
```
...
  gcrKeyPath: (path to GCR service account key)
  sshPrivateKeyPath: (path to SSH private key, used for node access)
  gkeConnectAgentServiceAccountKeyPath: (path to Connect agent service account key)
  gkeConnectRegisterServiceAccountKeyPath: (path to Hub registration service account key)
  cloudOperationsServiceAccountKeyPath: (path to Cloud Operations service account key)
...
```
- Modifiez la configuration pour spécifier le type de cluster user au lieu de admin :
```
...
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create
  #   user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster
  #   components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user
  #   workloads, but does not manage other clusters.
  type: user
...
```
- Enregistrez vos clusters dans un parc en spécifiant votre ID de projet dans le champ gkeConnect.projectID. Ce projet est appelé projet hôte du parc.
```
...
gkeConnect:
   projectID: my-project-123
...
```
  - Vous pouvez éventuellement ajouter gkeConnect.location à la spécification du cluster pour spécifier la région Google Cloud dans laquelle le parc et les services Connect s'exécutent. Cette appartenance régionale limite le trafic du service de parc à votre région. Si vous incluez gkeConnect.location dans la spécification de cluster, la région que vous spécifiez doit être identique à celle configurée dans clusterOperations.location. Si les régions sont différentes, la création du cluster échoue.
- Si l'API GKE On-Prem est activée dans votre projet Google Cloud, tous les clusters du projet sont automatiquement enregistrés dans l'API GKE On-Prem dans la région configurée dans clusterOperations.location.
  - Si vous souhaitez enregistrer tous les clusters du projet dans l'API GKE On-Prem, veillez à suivre la procédure décrite dans 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 pas enregistrer de clusters 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.
- Spécifiez l'adresse IP du nœud du plan de contrôle.
```
...
# Sample control plane config
controlPlane:
 nodePoolSpec:
   nodes:
   - address: 10.200.0.20
...
```
- Assurez-vous que les spécifications des clusters d'administrateur et d'utilisateur pour les adresses IP virtuelles et les pools d'adresses de l'équilibreur de charge sont complémentaires et qu'elles ne chevauchent pas les clusters existants. L'exemple suivant présente une paire de configurations de clusters d'administrateur et d'utilisateur, spécifiant l'équilibrage de charge et des pools d'adresses:
```
...
# Sample admin cluster config for load balancer and address pools
  loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.49
      ingressVIP: 10.200.0.50
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.50-10.200.0.70
...
...
# Sample user cluster config for load balancer and address pools
loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
...
```
  Les autres fichiers de configuration du cluster d'utilisateur sont identiques à ceux de la configuration du cluster d'administrateur.
- Spécifiez la densité de pods des nœuds de cluster.
```
...
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
  # podDensity specifies the pod density configuration.
  podDensity:
    # maxPodsPerNode specifies at most how many pods can be run on a single node.
    maxPodsPerNode: 110
...
```
  Pour les clusters d'utilisateur, les valeurs autorisées pour maxPodsPerNode sont 32-250. La valeur par défaut est 110 si elle n'est pas spécifiée. Une fois le cluster créé, cette valeur ne peut pas être mise à jour.
  
  La densité des pods est également limitée par les ressources IP disponibles de votre cluster. Pour plus de détails, consultez la section Mise en réseau de pods.

Créer le cluster d'utilisateur

Exécutez la commande bmctl pour appliquer la configuration du cluster d'utilisateur et créer le cluster :

bmctl create cluster -c USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

Remplacez les éléments suivants :

USER_CLUSTER_NAME : nom du cluster créé dans la section précédente.
ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Par exemple, pour un cluster d'utilisateur nommé user1 et un fichier kubeconfig de cluster d'administrateur dont le chemin d'accès est kubeconfig bmctl-workspace/admin/admin-kubeconfig, la commande est la suivante :

bmctl create cluster -c user1 --kubeconfig bmctl-workspace/admin/admin-kubeconfig

Exemples de configurations de cluster d'utilisateur

Pour obtenir des exemples de configurations de cluster d'utilisateur, consultez la section Clusters d'utilisateur dans les exemples de configurations de cluster.