Créer un cluster d'utilisateur dans un centre de données vSphere virtuel

Cette page explique comment créer un cluster d'utilisateur situé dans un centre de données différent de celui du cluster d'administrateur.

À partir de la version 1.9 d'Anthos Clusters on VMware (GKE On-Prem), vous pouvez créer des clusters d'administrateur et d'utilisateur ayant différents centres de données vSphere. Ce document explique comment utiliser cette fonctionnalité bêta publique.

Prerequisites

Assurez-vous que la version de votre poste de travail administrateur est mise à niveau vers la version 1.9 ou ultérieure.

Étape 1 : Créer un fichier de configuration de cluster d'utilisateur pour le nouveau cluster d'utilisateur

Pour plus d'informations sur la création de clusters d'utilisateur, consultez la page Créer un cluster d'utilisateur.

Lorsque vous créez un fichier de configuration pour un nouveau cluster d'utilisateur, vous devez inclure le champ vCenter.datacenter si vous souhaitez qu'il se trouve dans un centre de données distinct de celui du cluster d'administrateur. Lorsque vous incluez le champ vCenter.datacenter, vous devez également inclure les champs vCenter.cluster, vCenter.datastore et vCenter.networkName.

Le champ masterNode.vSphere.datastore est obligatoire si le cluster d'administrateur et le cluster d'utilisateur se trouvent dans des centres de données vSphere virtuels distincts. Il est recommandé de créer un datastore distinct pour chaque plan de contrôle de cluster d'utilisateur dans le centre de données du cluster, de sorte à ce que le plan de contrôle du cluster d'administrateur et les plans de contrôle du cluster d'utilisateur aient des domaines de défaillance de datastore isolés. Bien que vous puissiez utiliser le datastore du cluster d'administrateur pour les nœuds du plan de contrôle d'utilisateur, cela place les nœuds du plan de contrôle d'utilisateur et le cluster d'administrateur dans le même domaine de défaillance de datastore.

Dans cet exemple, le cluster d'administrateur se trouve dans le ADMIN_DATACENTER et le nouveau cluster d'utilisateur dans le USER_DATACENTER.

apiVersion: v1
kind: UserCluster
# ...
gkeOnPremVersion: 1.9.0-gke.x
# ...
vCenter:
  datacenter: USER_DATACENTER # Required
  cluster: USER_CLUSTER # Required if resourcePool is not specified.
  folder: USER_FOLDER # Optional
  resourcePool: USER_RESOURCE_POOL # Required if cluster is not specified.
  datastore: USER_DATASTORE # Required
  credentials: # Optional
    fileRef:
      path: USER_VCENTER_CREDENTIAL_PATH
      entry: vCenter
masterNode:
  vsphere:
    datastore: USER_MASTER_DATASTORE # Required.
network:
  vCenter:
    networkName: USER_NETWORK # Required

Étape 2 : Importer un modèle d'image de l'OS

Exécutez ensuite gkectl prepare pour importer le modèle d'image d'OS dans USER_DATACENTER.

gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_TARBALL --user-cluster-config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

  • BUNDLE_TARBALL par le chemin d'accès au package tarball du groupe 1.9.0-gke.x.
  • ADMIN_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
  • USER_CLUSTER_CONFIG par le chemin d'accès au fichier de configuration du cluster d'utilisateur.

Étape 3 : Créer le cluster d'utilisateur dans un centre de données distinct

Exécutez gkectl create pour créer le cluster d'utilisateur dans un centre de données distinct. Cette commande est identique à celle pour le même centre de données que le cluster d'administrateur.

gkectl create cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG

Comptes de service pour le nouveau cluster d'utilisateur

Un cluster d'utilisateur peut utiliser un autre compte de service vSphere, avec des vCenter.credentials différents de ceux du cluster d'administrateur. Le compte de service administrateur n'a besoin d'accéder qu'au centre de données d'administration, tandis que le compte de service utilisateur n'a besoin d'accéder qu'au centre de données utilisateur correspondant.

Règles de pare-feu pour le nouveau cluster d'utilisateur

Le cluster d'administrateur et le cluster d'utilisateur peuvent utiliser networkName dans différents VLAN et centres de données. Toutefois, la communication entre les VLAN doit être autorisée comme indiqué ci-dessous.

  • Les nœuds du cluster d'administrateur peuvent accéder au port 22 des adresses IP du nœud du cluster d'utilisateur. Cet accès est requis pour que le plan de contrôle d'utilisateur puisse créer des tunnels SSH vers les nœuds utilisateur.
  • Les nœuds utilisateur peuvent accéder au port 443 sur l'adresse IP virtuelle du plan de contrôle d'utilisateur. Cet accès est requis pour que les nœuds utilisateur et les pods puissent communiquer avec le serveur d'API.