Créer un cluster d'utilisateur (Controlplane V2)

Ce document explique comment créer un cluster d'utilisateur avec Controlplane V2 activé.

Avec le plan de contrôle V2, le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'utilisateur lui-même. Le plan de contrôle V2 est le paramètre par défaut et recommandé pour la création de clusters.

Présentation de la procédure

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

  1. Se connecter au poste de travail administrateur
    Le poste de travail administrateur est une VM disposant des outils nécessaires pour créer un cluster d'utilisateur.
  2. Remplir vos fichiers de configuration
    Spécifiez les détails de votre nouveau cluster en remplissant un fichier de configuration du cluster d'utilisateur, un fichier de configuration des identifiants et éventuellement un fichier de bloc d'adresses IP.
  3. (Facultatif) Importez des images d'OS dans vSphere et transférez des images de conteneurs vers la
    registre privé, le cas échéant.
    Exécutez gkectl prepare.
  4. Créer un cluster d'utilisateur
    Exécutez gkectl create cluster pour créer un cluster comme spécifié dans votre fichier de configuration.
  5. 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.

Avant de commencer

  • Assurez-vous d'avoir créé un poste de travail administrateur et un cluster d'administrateur .

  • Consultez le document de planification des adresses IP. Assurez-vous que vous disposez de suffisamment d'adresses IP et examinez à nouveau la manière dont vous souhaitez que les nœuds de votre cluster obtiennent leurs adresses IP : DHCP ou statique. Si vous décidez d'utiliser des adresses IP statiques, vous devez renseigner un fichier de bloc d'adresses IP contenant les adresses choisies.

  • Consultez la présentation de l'équilibrage de charge et réexaminez votre décision concernant le type d'équilibreur de charge que vous souhaitez utiliser. Vous pouvez utiliser l'équilibreur de charge MetalLB groupé ou configurer manuellement un équilibreur de charge de votre choix. Pour l'équilibrage de charge manuel, vous devez configurer l'équilibreur de charge avant de créer le cluster d'utilisateur.

  • Consultez la section vCenter. Déterminez si vous souhaitez utiliser des clusters vSphere distincts pour votre cluster d'administrateur et vos clusters d'utilisateur, et si vous souhaitez utiliser des centres de données distincts. Demandez-vous également si vous souhaitez utiliser des instances distinctes de vCenter Server.

  • Consultez la section nodePools. Déterminez le nombre de pools de nœuds dont vous avez besoin et le système d'exploitation que vous souhaitez exécuter dans chacun de vos pools.

1. Se connecter au poste de travail administrateur

Obtenez une connexion SSH à votre poste de travail administrateur.

Rappelez-vous que gkeadm a activé votre compte de service d'accès au composant sur le poste de travail administrateur.

Effectuez toutes les étapes décrites dans cette rubrique sur votre poste de travail administrateur dans le répertoire d'accueil.

2. Remplir le fichier de configuration

Lorsque gkeadm a créé votre poste de travail administrateur, il a généré un fichier de configuration nommé user-cluster.yaml. Ce fichier de configuration vous permet de créer votre cluster d'utilisateur.

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 GKE sur VMware. Par exemple : 1.15.0-gke.581

enableControlplaneV2

Définissez enableControlplaneV2 sur true.

enableDataplaneV2

Définissez enableDataplaneV2 sur true.

vCenter

Les valeurs définies dans la section vCenter du fichier de configuration du cluster d'administrateur sont globales. Autrement dit, elles s'appliquent au cluster d'administrateur et aux clusters d'utilisateur.

Pour chaque cluster d'utilisateur que vous créez, vous avez la possibilité de remplacer certaines des valeurs vCenter globales.

Pour remplacer l'une des valeurs vCenter globales, renseignez les champs appropriés dans la section vCenter du fichier de configuration de votre cluster d'utilisateur.

Vous pouvez en particulier utiliser des clusters vSphere distincts pour votre cluster d'administrateur et vos clusters d'utilisateur, ainsi que des centres de données distincts pour votre cluster d'administrateur et vos clusters d'utilisateur.

Utiliser un centre de données et un cluster vSphere

L'option par défaut consiste à utiliser un centre de données et un cluster vSphere pour le cluster d'administrateur et le cluster d'utilisateur. Pour cette option, ne définissez aucune valeur vCenter dans le fichier de configuration du cluster d'utilisateur. Les valeurs vCenter seront héritées du cluster d'administrateur.

Utiliser des clusters vSphere distincts

Si vous souhaitez créer un cluster d'utilisateur dans son propre cluster vSphere, spécifiez une valeur pour vCenter.cluster dans le fichier de configuration du cluster d'utilisateur.

Si votre cluster d'administrateur et votre cluster d'utilisateur se trouvent dans des clusters vSphere distincts, ils peuvent se trouver dans le même centre de données ou dans des centres de données différents.

Utiliser des centres de données vSphere distincts

Le cluster d'utilisateur et le cluster d'administrateur peuvent se trouver dans des centres de données différents. Dans ce cas, ils se trouvent également dans des clusters vSphere distincts.

Si vous spécifiez vCenter.datacenter dans le fichier de configuration du cluster d'utilisateur, vous devez également spécifier:

  • vCenter.networkName
  • vCenter.datastore ou vCenter.storagePolicyName
  • vCenter.cluster ou vCenter.resourcePool

Utiliser des comptes vCenter distincts

Un cluster d'utilisateur peut utiliser un autre compte vCenter que celui du cluster d'administrateur, avec un champ vCenter.credentials différent. Le compte vCenter du cluster d'administrateur a besoin d'accéder au centre de données du cluster d'administrateur, tandis que le compte vCenter du cluster d'utilisateur n'a besoin d'accéder qu'au centre de données du cluster d'utilisateur.

Utiliser des instances distinctes de vCenter Server

Dans certains cas, il est judicieux de créer un cluster d'utilisateur qui utilise sa propre instance de vCenter Server. Autrement dit, le cluster d'administrateur et un cluster d'utilisateur associé utilisent des instances différentes de vCenter Server.

Par exemple, dans un emplacement périphérique, vous pouvez avoir une machine physique exécutant vCenter Server et une ou plusieurs machines physiques exécutant ESXi. Vous pouvez ensuite utiliser votre instance locale de vCenter Server pour créer une hiérarchie d'objets vSphere, y compris des centres de données, des clusters, des pools de ressources, des datastores et des dossiers.

Remplissez l'intégralité de la section vCenter du fichier de configuration de votre cluster d'utilisateur. En particulier, spécifiez pour vCenter.address une valeur différente de l'adresse du serveur vCenter spécifiée dans le fichier de configuration du cluster d'administrateur. Exemple :

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Renseignez également le champ network.vCenter.networkName.

network

Décidez de quelle manière 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. Définissez network.ipMode.type sur "static", puis créez un fichier de bloc d'adresses IP qui fournit les adresses IP statiques. Pour obtenir un exemple de fichier de blocs d'adresses IP, consultez la section Exemple de fichiers de configuration remplis.

Si vous avez décidé d'utiliser des adresses IP statiques pour vos nœuds de calcul, renseignez le champ network.ipMode.ipBlockFilePath.

Les nœuds du plan de contrôle de votre cluster d'utilisateur doivent obtenir leurs adresses IP à partir d'une liste d'adresses statiques que vous fournissez. C'est le cas même si vos nœuds de calcul obtiennent leurs adresses à partir d'un serveur DHCP. Pour spécifier des adresses IP statiques pour les nœuds du plan de contrôle, remplissez la section network.controlPlaneIPBlock. Si vous souhaitez un cluster d'utilisateur haute disponibilité, spécifiez trois adresses IP. Sinon, spécifiez une adresse IP.

Spécifiez les serveurs DNS et NTP en remplissant la section hostConfig. Ces serveurs DNS et NTP sont destinés aux nœuds du plan de contrôle. Si vous utilisez des adresses IP statiques pour vos nœuds de calcul, ces serveurs DNS et NTP sont également destinés aux nœuds de calcul.

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.

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.

loadBalancer

Définissez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'utilisateur. Définissez-en une autre pour le service d'entrée de votre cluster d'utilisateur. Indiquez vos adresses IP virtuelles comme valeurs pour loadBalancer.vips.controlPlaneVIP et loadBalancer.vips.ingressVIP.

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

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

advancedNetworking

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

multipleNetworkInterfaces

Décidez si vous souhaitez configurer plusieurs interfaces réseau pour les pods et définissez multipleNetworkInterfaces en conséquence.

storage

Si vous souhaitez désactiver le déploiement des composants CSI vSphere, définissez storage.vSphereCSIDisabled sur true.

masterNode

Dans la section masterNode, vous pouvez spécifier le nombre de nœuds du plan de contrôle que vous souhaitez pour votre cluster d'utilisateur: un ou trois. Vous pouvez également spécifier un datastore pour les nœuds du plan de contrôle et indiquer si vous souhaitez activer le redimensionnement automatique pour ces nœuds.

Rappelez-vous que vous avez spécifié les adresses IP des nœuds du plan de contrôle dans la section network.controlPlaneIPBlock.

nodePools

Un pool de nœuds est un groupe de nœuds au sein d'un cluster qui possèdent tous la même configuration. Par exemple, les nœuds d'un pool peuvent exécuter Windows et les nœuds d'un autre pool peuvent exécuter Linux.

Vous devez spécifier au moins un pool de nœuds en remplissant la section nodePools.

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

antiAffinityGroups

Définissez antiAffinityGroups.enabled sur true ou false.

Ce champ indique si GKE sur VMware crée des règles anti-affinité Distributed Resource Scheduler (DRS) pour vos nœuds de calcul, avec pour effet de les répartir sur au moins trois hôtes physiques dans votre centre de données.

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

Notez les exigences suivantes pour les nouveaux clusters:

  • L'ID dans stackdriver.projectID doit être identique à l'ID 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. De plus, si gkeOnPremAPI.enabled correspond à 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é.

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 sont différents, la création du cluster échoue.

gkeOnPremAPI

À partir de la version 1.16, 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 stackdriver.clusterLocation.

  • Si vous souhaitez enregistrer tous les clusters du projet dans l'API GKE On-Prem, suivez 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 enregistrer aucun cluster dans le projet, désactivez gkeonprem.googleapis.com (nom de service pour l'API GKE On-Prem) dans le projet. Pour obtenir des instructions, consultez la section Désactiver des services.

usageMetering

Si vous souhaitez activer la mesure de l'utilisation de votre cluster, renseignez la section usageMetering.

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 pour les nouveaux clusters:

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

  • La région Google Cloud définie dans cloudAuditLogging.clusterLocation doit être identique à celle définie dans stackdriver.clusterLocation. De plus, si gkeOnPremAPI.enabled correspond à 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.

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

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.15.0-gke.581
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
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"
autoRepair:
  enabled: true

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

  • Les adresses IP statiques 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, même s'il n'y a que trois nœuds de calcul. L'adresse IP supplémentaire est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster.

  • Les serveurs DNS et NTP sont spécifiés dans la section hostConfig. Dans cet exemple, ces serveurs DNS et NTP sont destinés aux nœuds du plan de contrôle et aux nœuds de calcul. En effet, les nœuds de calcul possèdent des adresses IP statiques. Si les nœuds de calcul obtiennent leurs adresses IP à partir d'un serveur DHCP, ces serveurs DNS et NTP ne concerneront que les nœuds du plan de contrôle.

  • Les adresses IP statiques des trois nœuds de plan de contrôle sont spécifiées dans la section network.controlPlaneIPBlock du fichier de configuration du cluster d'utilisateur. Aucune adresse IP supplémentaire n'est nécessaire dans ce bloc.

  • Le champ masterNode.replicas est défini sur 3.

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

  • Les adresses IP virtuelles réservées pour les services de type LoadBalancer sont spécifiées dans la section loadBalancer.metalLB.addressPools du fichier de configuration du cluster d'utilisateur. Ces adresses IP virtuelles se trouvent sur le même VLAN que les nœuds de calcul et les nœuds du plan de contrôle. L'ensemble d'adresses IP virtuelles spécifié dans cette section doit inclure l'adresse IP virtuelle d'entrée et non celle du plan de contrôle.

  • Le fichier de configuration du cluster d'utilisateur n'inclut pas de section vCenter. Le cluster d'utilisateur utilise donc les mêmes ressources vSphere que le cluster d'administrateur.

Valider votre fichier de configuration

Une fois que vous avez rempli le fichier de configuration du cluster d'utilisateur, exécutez gkectl check-config pour vérifier que le fichier est valide :

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

  • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

  • USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

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-xxx. Pour en savoir plus sur la commande check-config, consultez la page Exécuter des vérifications préliminaires.

3. (Facultatif) Importez des images d'OS dans vSphere et transférez des images de conteneurs vers un registre privé

Exécutez gkectl prepare si l'une des conditions suivantes est remplie:

  • Votre cluster d'utilisateur se trouve dans un centre de données vSphere différent de votre cluster d'administrateur.

  • Votre cluster d'utilisateur possède un serveur vCenter différent de votre cluster d'administrateur.

  • Votre cluster d'utilisateur utilise un registre de conteneurs privé différent du registre privé utilisé par votre cluster d'administrateur.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

  • ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur

  • BUNDLE: chemin d'accès au fichier de bundle. Ce fichier se trouve sur votre poste de travail administrateur dans /var/lib/gke/bundles/. Exemple :

    /var/lib/gke/bundles/gke-onprem-vsphere-1.14.0-gke.421-full.tgz

  • USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

4. Créer un cluster d'utilisateur

Créez 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.

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

Mettre à niveau un cluster d'utilisateur

Suivez les instructions de la page Mettre à niveau Anthos clusters on VMware.

Supprimer un cluster

Pour supprimer un cluster d'utilisateur sur lequel Controlplane V2 est activé, suivez les instructions de la section Supprimer un cluster d'utilisateur.

Lorsque vous supprimez un cluster d'utilisateur sur lequel le plan de contrôle V2 est activé, le disque de données est automatiquement supprimé.

Dépannage

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

Étapes suivantes