Créer des clusters d'utilisateur

Dans Google Distributed Cloud, 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.

Prérequis

  • La dernière version de bmctl est téléchargée (gs://anthos-baremetal-release/bmctl/1.30.100-gke.96/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.
  • La station 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 ou ultérieure de Google Distributed Cloud, 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). 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.

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.

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

  2. 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
      ...
      
    • 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 adhésion 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 ne sont pas identiques, 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 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 du service de l'API GKE On-Prem) dans le projet. Pour obtenir des instructions, consultez la page Désactiver des services.

    • Spécifiez l'adresse IP du nœud de 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 des adresses IP virtuelles et des pools d'adresses sont complémentaires et ne recoupent pas celles des clusters existants. L'exemple suivant montre un exemple de configuration de cluster d'administrateur et de cluster 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 de clusters 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 l'élément suivant :

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