Créer un cluster d'utilisateur à utiliser avec des domaines de topologie

Dans Google Distributed Cloud, vos charges de travail s'exécutent sur un ou plusieurs clusters d'utilisateur. Cette page explique comment créer un cluster d'utilisateur à utiliser dans les domaines de topologie Google Distributed Cloud. Vous devez disposer de la version 1.31 ou ultérieure de Google Distributed Cloud pour utiliser les domaines de topologie.

Pour configurer un domaine de topologie, vous devez activer le cluster avancé. Notez les limites suivantes avec l'aperçu avancé du cluster:

  • Vous ne pouvez activer le cluster avancé qu'au moment de la création du cluster pour les nouveaux clusters 1.31.
  • Une fois le cluster avancé activé, vous ne pourrez plus le mettre à niveau vers la version 1.32. N'activez le cluster avancé que dans un environnement de test.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui configurent, surveillent et gèrent l'infrastructure technologique. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de commencer

Présentation de la procédure

Voici les principales étapes à suivre pour créer un cluster d'utilisateur à l'aide de gkectl:

  1. Remplir le fichier de configuration de votre cluster d'utilisateur
    Spécifiez les détails de votre nouveau cluster dans le fichier de configuration du cluster d'utilisateur.
  2. Remplir votre fichier de bloc d'adresses IP
    Spécifiez les adresses IP de la passerelle, du masque de réseau, des nœuds de plan de contrôle et, éventuellement, des nœuds de calcul dans un fichier de bloc d'adresses IP.
  3. Créer un cluster d'utilisateur
    Exécutez gkectl create cluster pour créer un cluster comme spécifié dans vos fichiers de configuration.
  4. Vérifier que votre cluster d'utilisateur 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'utilisateur en cours d'exécution dans lequel vous pourrez déployer vos charges de travail.

Remplir le fichier de configuration de votre cluster d'utilisateur

Si vous avez utilisé gkeadm pour créer le poste de travail administrateur, gkeadm a généré un modèle pour le fichier de configuration de votre cluster d'utilisateur nommé user-cluster.yaml. De plus, gkeadm a rempli certains champs pour vous.

Si vous n'avez pas utilisé gkeadm pour créer votre poste de travail administrateur, vous pouvez utiliser gkectl pour générer un modèle pour le fichier de configuration de votre cluster d'utilisateur.

Pour générer un modèle pour le fichier de configuration de votre cluster d'utilisateur, exécutez la commande suivante :

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Remplacez les éléments suivants :

OUTPUT_FILENAME : chemin d'accès de votre choix pour le modèle généré. Si vous omettez cette option, gkectl nomme le fichier user-cluster.yaml et le place dans le répertoire actuel.

VERSION : numéro de version souhaité. Exemple : gkectl create-config cluster --gke-on-prem-version=1.31.0-gke.889.

Familiarisez-vous avec le fichier de configuration en analysant le fichier de configuration du cluster d'utilisateur. 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

Saisissez le nom de votre choix pour le cluster d'utilisateur dans le champ name.

gkeOnPremVersion

Ce champ est déjà renseigné. Il spécifie la version de Google Distributed Cloud. Par exemple, 1.31.0-gke.889.

enableAdvancedCluster

Définissez enableAdvancedCluster sur true.

enableControlplaneV2

Controlplane V2 est obligatoire pour tous les clusters d'utilisateurs de la version 1.30 ou ultérieure. Définissez enableControlplaneV2 sur true.

Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute sur les nœuds du cluster d'utilisateur lui-même.

enableDataplaneV2

Définissez enableDataplaneV2 sur true.

vCenter

Supprimez l'intégralité de cette section. Vous devez plutôt configurer les informations vCenter dans le fichier de configuration de l'infrastructure vSphere par domaine de topologie.

network

  • Supprimez ce qui suit du fichier de configuration:

    • L'intégralité de la section network.hostConfig. Ces informations sont configurées dans le fichier de configuration de l'infrastructure vSphere par domaine de topologie.
    • Le champ network.vCenter.networkName Ce champ est configuré dans le fichier de configuration de l'infrastructure vSphere par domaine de topologie.
    • L'intégralité de la section network.controlPlaneIPBlock. Les adresses IP de la passerelle, du masque de réseau et des nœuds du plan de contrôle sont configurées dans un fichier de bloc d'adresses IP.

  • Définissez network.ipMode.ipBlockFilePath sur le chemin d'accès au fichier de bloc d'adresses IP.

  • Décidez comment vous souhaitez que vos nœuds de calcul obtiennent leurs adresses IP. Vous disposez des options suivantes :

    • Depuis un serveur DHCP que vous avez configuré à l'avance. Définissez network.ipMode.type sur "dhcp".

    • À partir d'une liste d'adresses IP statiques que vous fournissez dans le fichier de bloc d'adresses IP. Définissez network.ipMode.type sur "static".

    Les nœuds du plan de contrôle pour votre cluster d'utilisateur doivent obtenir leurs adresses IP à partir d'une liste d'adresses statiques que vous fournissez dans le fichier de bloc d'adresses IP. C'est le cas même si vos nœuds de calcul obtiennent leurs adresses à partir d'un serveur DHCP.

    Que vous utilisiez un serveur DHCP ou que vous spécifiiez une liste d'adresses IP statiques, vous devez disposer de suffisamment d'adresses IP disponibles pour votre cluster d'utilisateur. Pour connaître le nombre d'adresses IP dont vous avez besoin, consultez la section Planifier vos adresses IP.

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

loadBalancer

  • Définissez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'utilisateur. Indiquez votre adresse IP virtuelle comme valeur pour loadBalancer.vips.controlPlaneVIP.

  • Définissez-en une autre pour le service d'entrée de votre cluster d'utilisateur. Indiquez votre adresse IP virtuelle comme valeur pour loadBalancer.vips.ingressVIP.

  • Définissez loadBalancer.kind sur "ManualLB", puis remplissez la section manualLB. Pour en savoir plus, consultez la page sur l'équilibrage de charge manuel.

advancedNetworking

Si vous envisagez de créer une passerelle NAT de sortie, définissez advancedNetworking sur true.

multipleNetworkInterfaces

Définissez multipleNetworkInterfaces sur false. Les interfaces réseau multiples pour les pods ne sont pas compatibles avec les domaines de topologie.

storage

Définissez storage.vSphereCSIDisabled sur true pour désactiver le déploiement des composants CSI vSphere.

masterNode

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

  • Seuls les clusters haute disponibilité (HA) sont acceptés. Définissez le champ replicas sur 3 pour spécifier que le cluster aura trois nœuds de plan de contrôle.

  • Pour activer le redimensionnement automatique des nœuds du plan de contrôle, définissez autoResize.enabled sur true.

  • Supprimez l'intégralité de la section masterNode.vsphere.

  • Renseignez le champ masterNode.topologyDomains avec le nom du domaine de topologie dans lequel vous souhaitez que les nœuds du plan de contrôle se trouvent.

nodePools

Un pool de nœuds est un groupe de nœuds de calcul au sein d'un cluster qui possèdent tous la même configuration. Par exemple, vous pouvez configurer un domaine de topologie distinct pour chaque pool de nœuds. Vous devez spécifier au moins un pool de nœuds en remplissant la section nodePools.

Pour chaque pool de nœuds que vous spécifiez:

  • Dans le champ nodePools[i].topologyDomains, indiquez le nom du domaine de topologie dans lequel vous souhaitez que le pool de nœuds se trouve.

  • Supprimez tous les champs de la section nodePools[i].vsphere, à l'exception de nodePools[i].vsphere.tags. Vous spécifiez ces informations dans le fichier de configuration de l'infrastructure vSphere par domaine de topologie.

# advanced-cluster-change #

Définissez nodePools[i].osImageType sur ubuntu_cgroupv2 ou ubuntu_containerd.

Pour en savoir plus sur les pools de nœuds, consultez les pages Pools de nœuds et Créer et gérer des pools de nœuds.

antiAffinityGroups

Définissez antiAffinityGroups.enabled sur false. Les règles d'anti-affinité Distributed Resource Scheduler (DRS) ne sont pas compatibles avec les domaines de topologie.

stackdriver

Renseignez la section stackdriver pour activer Cloud Logging et Cloud Monitoring pour votre cluster.

Notez les exigences suivantes :

  • 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 la même que 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.

gkeConnect

Votre cluster d'utilisateur doit être enregistré dans un parc Google Cloud .

Renseignez la section gkeConnect pour spécifier un projet hôte du parc et un compte de service associé. L'ID dans 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.

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 dans votre fichier de configuration, 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

Cette section explique comment les clusters sont enregistrés dans l'API GKE On-Prem.

L'outil de ligne de commande gkectl est le seul outil de gestion du cycle de vie des clusters disponible pour les clusters utilisant des domaines de topologie. Bien que la console Google Cloud , Google Cloud CLI et Terraform ne soient pas compatibles avec les clusters utilisant des domaines de topologie, vous pouvez enregistrer le cluster dans l'API GKE On-Prem lors de sa création.

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

cloudAuditLogging

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

Notez les exigences suivantes :

# advanced-cluster-change #

Définissez cloudAuditLogging.serviceAccountKeyPath sur le même chemin que stackdriver.serviceAccountKeyPath.

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

  • La région dans cloudAuditLogging.clusterLocation doit être identique à celle définie dans gkeConnect.location (si le champ est inclus dans votre fichier de configuration) et stackdriver.clusterLocation. 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.

preparedSecrets

Supprimez le champ preparedSecrets. Les identifiants préparés ne sont pas acceptés lorsque les domaines de topologie sont activés.

Exemple de fichiers de configuration préremplis

Voici un exemple de fichier de bloc d'adresses IP et de fichier de configuration de cluster d'utilisateur :

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4
  - netmask: 255.255.255.0
    gateway: 100.115.223.254
    ips:
    - ip: 100.115.222.205
      hostname: cp-1
      isControlPlane: true
    - ip: 100.115.222.206
      hostname: cp-2
      isControlPlane: true
    - ip: 100.115.222.207
      hostname: cp-3
      isControlPlane: true

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.31.0-gke.889
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
loadBalancer:
  vips:
    controlPlaneVIP: "100.115.222.200"
    ingressVIP: "172.16.21.30"
  kind: "ManualLB"
  manualLB:
    ingressHTTPNodePort: 32527
    ingressHTTPSNodePort: 30139
    controlPlaneNodePort: 30968
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  topologyDomains:
  - "domain1"
antiAffinityGroups:
  enabled: false
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Voici les points importants à comprendre dans l'exemple précédent :

  • Le champ nodePools.replicas est défini sur 3, ce qui signifie qu'il y a trois nœuds de calcul dans "worker-node-pool". Tous les nœuds de calcul utilisent des adresses IP statiques, car network.ipMode.type est défini sur "static".

  • Les adresses IP des nœuds de plan de contrôle et des nœuds de calcul sont spécifiées dans un fichier de bloc d'adresses IP. Le fichier de blocs d'adresses IP comporte quatre adresses pour les nœuds de calcul, même s'il n'y a que trois nœuds de calcul. L'adresse IP du nœud de calcul supplémentaire est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster. Les adresses IP des nœuds du plan de contrôle sont associées au flag isControlPlane: true.

  • Les clusters avancés, Controlplane V2 et Dataplane V2 sont activés.

  • Le champ masterNode.replicas est défini sur 3. Le cluster dispose donc d'un plan de contrôle à haute disponibilité.

  • L'adresse IP virtuelle du plan de contrôle se trouve dans le même VLAN que les nœuds du plan de contrôle, et l'adresse IP virtuelle d'entrée se trouve dans le même VLAN que les nœuds de calcul.

Remplir votre fichier de bloc d'adresses IP

Copiez le modèle du fichier de bloc d'adresses IP dans le fichier du répertoire que vous avez spécifié dans le champ network.ipMode.ipBlockFilePath du fichier de configuration du cluster d'utilisateur. Créez des fichiers de bloc d'adresses IP distincts pour le cluster d'administrateur et pour chaque cluster d'utilisateur.

Ajoutez les adresses IP de la passerelle, du masque de réseau et des nœuds de plan de contrôle au fichier de blocage des adresses IP. Pour chaque adresse IP de nœud de plan de contrôle, ajoutez isControlPlane: true, comme indiqué dans l'exemple précédent. Si vous souhaitez un cluster d'utilisateur à haute disponibilité, spécifiez trois adresses IP. Sinon, spécifiez une seule adresse IP. Le nombre d'adresses IP que vous spécifiez pour les nœuds de plan de contrôle doit correspondre au nombre indiqué dans le champ masterNode.replicas du fichier de configuration du cluster d'utilisateur.

Si network.ipMode.type est défini sur "static", ajoutez les adresses IP des nœuds de calcul au fichier de bloc d'adresses IP. Veillez à spécifier une adresse IP supplémentaire à utiliser lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster.

Chaque adresse de passerelle du fichier de bloc d'adresses IP doit correspondre à l'adresse spécifiée dans un champ topologyDomains[i].network.gateway du fichier de configuration de l'infrastructure vSphere. Pour en savoir plus, consultez l'exemple de domaines de topologie.

Créer un cluster d'utilisateur

Exécutez la commande suivante pour créer un cluster d'utilisateur :

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Localiser le fichier kubeconfig du cluster d'utilisateur

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

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

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

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

NAME
my-user-cluster

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

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Configurer votre PodTemplate

Le libellé de topologie est renseigné dans les libellés des nœuds du domaine de topologie. À moins que la configuration de votre domaine de topologie n'ait utilisé la contrainte par défaut, "topology.kubernetes.io/zone", comme clé de topologie, vous devez configurer la clé de topologie dans le modèle de pod de votre déploiement, de votre StatefulSet ou de votre ReplicaSet, le cas échéant.

Par exemple, supposons que vous ayez défini la clé dans le libellé de la topologie comme "topology.examplepetstore.com/zone". Dans PodTemplate, vous spécifiez la clé comme valeur du champ topologySpreadConstraints.topologyKey. Cela permet au planificateur Kubernetes de distribuer les pods sur le domaine de topologie afin de garantir une haute disponibilité et d'éviter une surconcentration dans une zone donnée en cas de défaillance.

Dépannage

Consultez la section Dépanner la création et la mise à niveau du cluster.

Étape suivante