Créer des clusters d'utilisateur dans une configuration multicluster

Dans Anthos clusters on Bare Metal, les clusters 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.

Prerequisites

La dernière version de bmctl est téléchargée (gs://anthos-baremetal-release/bmctl/1.11.8/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 des clusters d'utilisateur cibles.
Clé SSH utilisée pour créer un cluster d'utilisateur disponible pour l'utilisateur "root" ou "SUDO" sur tous les nœuds du cluster 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 des clusters Anthos sur solution Bare Metal, vous pouvez activer ou désactiver SELinux avant ou après la création des clusters, ou leurs mises à niveau. SELinux est activé par défaut sur Red Hat Enterprise Linux (RHEL) et CentOS. Si SELinux est désactivé sur vos machines hôtes ou si vous n'êtes pas sûr, consultez la section Sécuriser vos conteneurs à l'aide de SELinux pour savoir comment l'activer.

Les clusters Anthos sur solution Bare Metal ne sont compatibles avec SELinux que dans les systèmes RHEL et CentOS.

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 avec 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

Modifiez le fichier de configuration en apportant les modifications suivantes :

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
....

Assurez-vous que les spécifications des clusters d'administrateur et d'utilisateur des adresses IP virtuelles et des pools d'adresses sont complémentaires et ne recoupent pas celles des clusters existants. Vous trouverez ci-dessous un exemple de configuration de cluster d'administrateur et de cluster d'utilisateur spécifiant l'équilibrage de charge et les 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 de clusters d'utilisateur sont identiques à ceux de la configuration du cluster d'administrateur.
Spécifiez la densité du pod des nœuds de cluster et l'environnement d'exécution du conteneur :
```
....
# 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
  # containerRuntime specifies which container runtime to use for scheduling containers on nodes.
  # containerd and docker are supported.
  containerRuntime: containerd
....
```
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.

L'environnement d'exécution du conteneur par défaut est containerd. Vous pouvez également utiliser Docker. Pour en savoir plus sur la modification de votre environnement d'exécution, consultez notre guide de modification de l'environnement d'exécution des conteneurs.

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.