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 Google Distributed Cloud version 1.31 ou ultérieure pour utiliser les domaines de topologie.

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

  • Vous ne pouvez activer le cluster avancé qu'au moment de la création des nouveaux clusters 1.31.
  • Une fois le cluster avancé activé, vous ne pourrez pas 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 Google Cloud le contenu, consultez Rôles utilisateur et tâches courantes de GKE.

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 le fichier de configuration de l'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 l'infrastructure vSphere
    Spécifiez les détails de vos domaines de topologie dans un fichier de configuration de l'infrastructure vSphere.
  3. Remplir le fichier de bloc d'adresses IP
    Spécifiez les adresses IP de la passerelle, du masque de sous-réseau et des nœuds du 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 conteneurs 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 Créer un poste de travail administrateur. La station de travail d'administrateur dispose des outils dont vous avez besoin pour créer votre cluster d'administrateur. Suivez 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 pour les trois nœuds du plan de contrôle et une adresse IP virtuelle du plan de contrôle.

  • Configurez votre équilibreur de charge pour l'équilibrage de charge manuel. Votre équilibreur de charge doit être configuré avant de créer le cluster d'administrateur.

  • Consultez la privateRegistry section et décidez si vous souhaitez utiliser un registre public ou privé pour les composants 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 proxy serveur, assurez-vous d' ajouter les API requises et l'adresse Artifact Registry à la liste d'autorisation.

  • Rassemblez les informations dont vous avez besoin pour accéder à chaque instance de vCenter Server. Vous aurez besoin de ces informations pour remplir la Secret section et la VSphereInfraConfig.credentials.vCenters section dans le fichier de configuration de l'infrastructure vSphere. Pour savoir comment obtenir les informations nécessaires, consultez les sections suivantes :

Remplir le fichier de configuration de votre cluster d'administrateur

Si vous avez utilisé gkeadm pour créer votre station 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 active les clusters avancés, ce qui est nécessaire pour configurer les domaines de topologie.

infraConfigFilePath

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

vCenter

Supprimez l'intégralité de cette section. À la place, configurez les informations de vCenter Server dans le fichier de configuration de l'infrastructure vSphere.

network

  • Supprimez les éléments suivants 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 sous-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 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" et supprimez la manualLB section.

  • 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é de 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 du domaine de topologie au adminMaster.topologyDomainschamp. 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 proxy section.

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

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 d'administrateur dans un Google Cloud parc en remplissant la gkeConnect section. 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'gkectl outil de ligne de commande est le seul outil de gestion du cycle de vie des clusters disponible pour les clusters utilisant des domaines de topologie. Bien que la Google Cloud console, Google Cloud CLI et Terraform ne soient pas compatibles avec les clusters utilisant des domaines de topologie, vous pouvez éventuellement 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 Google Cloud projet, 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

Remplissez la stackdriver section 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 Google Cloud région définie dans stackdriver.clusterLocation doit être identique à celle définie dans cloudAuditLogging.clusterLocation et gkeConnect.location. De plus, si gkeOnPremAPI.enabled est 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 Google Cloud région définie dans cloudAuditLogging.clusterLocation doit être identique à celle définie dans stackdriver.clusterLocation et gkeConnect.location (si le champ est inclus dans votre fichier de configuration). De plus, si gkeOnPremAPI.enabled est 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, dans un datastore vSphere n'est pas acceptée.

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 le osImageType. sur ubuntu_cgv2.

preparedSecrets

Supprimez le champ preparedSecrets. Les identifiants préparés ne sont pas compatibles 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_cgv2"

Remplir le fichier de configuration de l'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'utilisateur gérés.

Secret

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

VSphereInfraConfig.name

Remplissez le VSphereInfraConfig,name champ.

VSphereInfraConfig.credentials.vCenters

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

VSphereInfraConfig,topologyDomains

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

Remplir le 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 network.ipMode.ipBlockFilePath champ du fichier de configuration du cluster d'administrateur. Ajoutez les adresses IP de la passerelle, du masque de sous-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. Sauf si la configuration de votre domaine de topologie utilise 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, StatefulSet ou ReplicaSet, le cas échéant.

Par exemple, supposons que vous ayez défini la clé dans le libellé de topologie comme "topology.examplepetstore.com/zone". Dans le 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 concentration excessive dans une zone 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 maintenant sauvegarder admin-cluster-ssh-key à l'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 un domaine de topologie