Créer un cluster d'administrateur à utiliser dans les domaines de topologie

Cette page explique comment créer un cluster d'administrateur à utiliser dans les domaines de topologie Google Distributed Cloud. Le cluster d'administrateur gère les clusters d'utilisateur qui exécutent vos charges de travail. 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.

Pour en savoir plus sur le cluster d'administrateur, consultez la présentation de l'installation.

Présentation de la procédure

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

  1. Remplir votre fichier de configuration d'administrateur
    Spécifiez les détails de votre nouveau cluster d'administrateur en remplissant un fichier de configuration du cluster d'administrateur.
  2. Remplir le fichier de configuration de votre infrastructure vSphere
    Spécifiez les détails de vos domaines de topologie dans un fichier de configuration de l'infrastructure vSphere.
  3. Remplir votre fichier de bloc d'adresses IP
    Spécifiez les adresses IP de la passerelle, du masque de réseau et des nœuds de plan de contrôle dans un fichier de bloc d'adresses IP.
  4. Obtenir des images de l'OS
    Téléchargez le bundle Google Distributed Cloud normal. Exécutez ensuite gkectl prepare, qui importe les images d'OS dans vSphere et transfère les images de conteneur vers le registre privé, le cas échéant.
  5. Créez un cluster d'administrateur.
    Utilisez gkectl pour créer un cluster d'administrateur comme spécifié dans vos fichiers de configuration terminés. Lorsque Google Distributed Cloud crée un cluster d'administrateur, il déploie un cluster Kubernetes in Docker (kind) pour héberger temporairement les contrôleurs Kubernetes nécessaires à la création du cluster d'administrateur. Ce cluster temporaire est appelé cluster d'amorçage. Les clusters d'utilisateur sont créés et mis à niveau par leur administrateur de gestion sans utiliser de cluster d'amorçage.
  6. Vérifiez que votre cluster d'administrateur 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'administrateur en cours d'exécution que vous pourrez utiliser pour créer et gérer des clusters d'utilisateur dans des domaines de topologie.

Avant de commencer

  • Assurez-vous d'avoir configuré votre poste de travail administrateur et de pouvoir vous y connecter, comme décrit dans la section Créer un poste de travail administrateur. Le poste de travail d'administrateur dispose des outils dont vous avez besoin pour créer votre cluster d'administrateur. Effectuez toutes les étapes de ce document sur votre poste de travail administrateur.

  • Consultez le document de planification des adresses IP. Assurez-vous de disposer de suffisamment d'adresses IP disponibles pour les trois nœuds de plan de contrôle et une adresse IP virtuelle de plan de contrôle.

  • Configurez votre équilibreur de charge pour l'équilibrage de charge manuel. Vous devez configurer votre équilibreur de charge avant de créer le cluster d'administrateur.

  • Consultez la section privateRegistry et décidez si vous souhaitez utiliser un registre public ou privé pour les composants de Google Distributed Cloud.

  • Examinez le champ osImageType et choisissez le type de système d'exploitation à exécuter sur vos nœuds de cluster d'administrateur.

  • Si votre organisation exige que le trafic sortant passe par un serveur proxy, veillez à ajouter à la liste d'autorisation les API requises et l'adresse d'Artifact Registry.

  • Rassemblez les informations dont vous avez besoin pour accéder à chaque instance de vCenter Server. Vous avez besoin de ces informations pour remplir les sections Secret et VSphereInfraConfig.credentials.vCenters du fichier de configuration de l'infrastructure vSphere. Pour obtenir les informations nécessaires, consultez les éléments suivants:

Remplir le fichier de configuration de votre cluster d'administrateur

Si vous avez utilisé gkeadm pour créer votre poste de travail administrateur, il a généré un fichier de configuration nommé admin-cluster.yaml.

Si vous n'avez pas utilisé gkeadm pour créer votre poste de travail administrateur, générez admin-cluster.yaml en exécutant la commande suivante sur votre poste de travail administrateur:

gkectl create-config admin

Ce fichier de configuration vous permet de créer votre cluster d'administrateur.

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

Si vous souhaitez spécifier un nom pour votre cluster d'administrateur, renseignez le champ name.

bundlePath

Le bundle est un fichier compressé contenant les composants du cluster. Il est inclus dans le poste de travail d'administrateur. Ce champ est déjà renseigné.

enableAdvancedCluster

Définissez enableAdvancedCluster sur true. Cela permet d'activer les clusters avancés, qui sont nécessaires pour configurer les domaines de topologie.

infraConfigFilePath

Ajoutez le chemin d'accès complet au fichier de configuration de l'infrastructure vSphere dans le champ infraConfigFilePath.

vCenter

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

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éfinissez network.ipMode.type sur static.

  • 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 loadBalancer.kind sur "ManualLB", puis supprimez la section manualLB.

  • Réservez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'administration. Indiquez votre adresse IP virtuelle comme valeur pour loadBalancer.vips.controlPlaneVIP.

Pour en savoir plus, consultez la page Adresses IP virtuelles dans le sous-réseau du cluster d'administrateur.

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.

adminMaster

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

  • Les clusters d'administrateur doivent comporter trois nœuds de plan de contrôle. Définissez le champ replicas dans la section adminMaster sur 3.

  • Si vous souhaitez spécifier un domaine de topologie spécifique à utiliser par les nœuds du plan de contrôle, ajoutez le nom de domaine de topologie au champ adminMaster.topologyDomains. Si vous ne spécifiez pas de nom ici, vous devez en définir un dans vSphereInfraConfig.defaultTopologyDomain dans le fichier de configuration de l'infrastructure vSphere.

proxy

Si le réseau qui contiendra vos nœuds de cluster d'administrateur se trouve derrière un serveur proxy, remplissez la section proxy.

privateRegistry

Décidez où vous souhaitez conserver les images de conteneur pour les composants Google Distributed Cloud. Vous disposez des options suivantes :

  • Artifact Registry

  • Votre propre registre Docker privé.

    Si vous souhaitez utiliser votre propre registre privé, remplissez la section privateRegistry.

componentAccessServiceAccountKeyPath

Google Distributed Cloud utilise votre compte de service d'accès au composant pour télécharger les composants de cluster à partir d'Artifact Registry. Ce champ contient le chemin d'accès à un fichier de clé JSON pour votre compte de service d'accès au composant.

Ce champ est déjà renseigné.

gkeConnect

Enregistrez votre cluster administrateur dans un parc Google Cloud en remplissant la section gkeConnect. 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, 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 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. La région gkeOnPremAPI.location doit être identique à celle spécifiée dans cloudAuditLogging.clusterLocation, gkeConnect.location et stackdriver.clusterLocation. Si les régions ne sont pas identiques, la création du cluster échoue.

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

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.

cloudAuditLogging

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

Notez les exigences suivantes pour les nouveaux clusters :

  • Étant donné que enableAdvancedCluster est défini sur true, vous devez spécifier le même chemin d'accès dans cloudAuditLogging.serviceAccountKeyPath et stackdriver.serviceAccountKeyPath.

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

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

clusterBackup

Supprimez cette section. La sauvegarde du cluster d'administrateur sur un datastore vSphere n'est pas prise en charge.

autoRepair

Si vous souhaitez activer la réparation automatique des nœuds pour votre cluster d'administrateur, définissez autoRepair.enabled sur true.

secretsEncryption

Étant donné que enableAdvancedCluster est défini sur true, supprimez cette section.

osImageType

Définissez osImageType. à ubuntu_cgroupv2 et ubuntu_containerd.

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 configuration de cluster d'administrateur renseigné. La configuration active certaines des fonctionnalités disponibles, mais pas toutes.

vc-01-admin-cluster.yaml

apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.31.0-gke.1-full.tgz"
enableAdvancedCluster: true
infraConfigFilePath: "/my-config-folder/vsphere-infrastructure-config.yaml"
network:
  serviceCIDR: "10.96.232.0/24"
  podCIDR: "192.168.0.0/16"
  ipMode:
    type: "static"
    ipBlockFilePath: "/my-config-folder/admin-cluster-ipblock.yaml"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.59"
  kind: "ManualLB"
antiAffinityGroups:
  enabled: false
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3
  topologyDomains: "admin-cluster-domain"
componentAccessServiceAccountKeyPath: "sa-key.json"
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"
  disableVsphereResourceMetrics: false
autoRepair:
  enabled: true
osImageType: "ubuntu_containerd"

Remplir le fichier de configuration de votre infrastructure vSphere

Copiez le modèle du fichier de configuration de l'infrastructure vSphere dans le fichier du répertoire que vous avez spécifié dans le champ infraConfigFilePath du fichier de configuration du cluster d'administrateur. Il n'existe qu'un seul fichier de configuration de l'infrastructure vSphere pour le cluster d'administrateur et tous les clusters d'utilisateurs gérés.

Secret

Remplissez la section Secret dans le fichier de configuration de l'infrastructure vSphere. Cette section décrit le secret des identifiants vSphere qui stocke les identifiants de chaque serveur vCenter.

VSphereInfraConfig.name

Renseignez le champ VSphereInfraConfig,name.

VSphereInfraConfig.credentials.vCenters

Pour chaque Secret, ajoutez une section VSphereInfraConfig.credentials.vCenters correspondante.

VSphereInfraConfig,topologyDomains

Remplissez la section VSphereInfraConfig.topologyDomains pour définir les domaines de topologie.

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'administrateur. Ajoutez les adresses IP de la passerelle, du masque de réseau et des trois nœuds du plan de contrôle. Pour chaque adresse IP de nœud du plan de contrôle, ajoutez isControlPlane: true, comme illustré dans l'exemple pour les domaines de topologie.

Obtenir des images de l'OS

  1. Téléchargez le bundle Google Distributed Cloud normal sur le poste de travail administrateur:

    gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz /var/lib/gke/bundles/gke-onprem-vsphere-VERSION.tgz

    Remplacez VERSION par la version de Google Distributed Cloud que vous souhaitez installer.

    Cette commande télécharge le bundle normal. Ne téléchargez pas le bundle complet, car il n'est pas compatible avec les clusters avancés.

  2. Exécutez gkectl prepare pour initialiser votre environnement vSphere :

    gkectl prepare --config ADMIN_CLUSTER_CONFIG

    Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès à la configuration du cluster d'administrateur.

    La commande gkectl prepare exécute les tâches préparatoires suivantes :

    • Importe les images d'OS vers vSphere et les marque comme modèles de VM.

    • Transfère les images de conteneurs vers votre registre, si vous utilisez un registre Docker privé.

    • Valide, éventuellement, des attestations de version des images de conteneur, vérifiant ainsi que les images ont été conçues et signées par Google, et sont prêtes pour le déploiement.

Créez le cluster d'administrateur :

Créez le cluster d'administrateur :

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Reprendre la création du cluster d'administrateur après un échec

Si la création du cluster d'administrateur échoue ou est annulée, vous pouvez exécuter à nouveau la commande create :

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Localiser le fichier kubeconfig du cluster d'administrateur

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

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

kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

NAME
gke-admin-tqk8x

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

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

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

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

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

admin-cp-vm-1   Ready    control-plane,master   ...
admin-cp-vm-2   Ready    control-plane,master   ...
admin-cp-vm-3   Ready    control-plane,master   ...

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.

Pour en savoir plus sur la configuration de topologySpreadConstraints, consultez la section Contraintes de répartition de la topologie des pods dans la documentation Kubernetes.

Sauvegarder des fichiers

Nous vous recommandons de sauvegarder le fichier kubeconfig de votre cluster d'administrateur. Autrement dit, copiez le fichier kubeconfig de votre poste de travail administrateur vers un autre emplacement. Ainsi, si vous perdez l'accès au poste de travail administrateur ou si le fichier kubeconfig de votre poste de travail administrateur est supprimé par erreur, vous avez toujours accès au cluster d'administrateur.

Nous vous recommandons également de sauvegarder la clé SSH privée de votre cluster d'administrateur. Si vous perdez l'accès au cluster d'administrateur, vous pouvez toujours utiliser SSH pour vous connecter aux nœuds du cluster d'administrateur. Cela vous permettra de résoudre et d'examiner les problèmes de connectivité au cluster d'administrateur.

Extrayez la clé SSH du cluster d'administrateur dans un fichier nommé admin-cluster-ssh-key :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \
    -o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key

Vous pouvez désormais sauvegarder admin-cluster-ssh-key à un autre emplacement de votre choix.

Dépannage

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

Étape suivante

Créer un cluster d'utilisateur à utiliser dans le domaine de topologie