Vous consultez la documentation d'une version précédente de GKE On-Prem. Consulter la documentation la plus récente

Créer des clusters d'utilisateur supplémentaires

Cette page explique comment créer des clusters d'utilisateur supplémentaires. Pour créer des clusters d'utilisateur supplémentaires, vous devez copier le fichier de configuration GKE On-Prem utilisé pour déployer vos clusters. Vous devez modifier le fichier copié pour répondre à vos attentes concernant les nouveaux clusters d'utilisateur, puis l'utiliser pour créer le cluster.

Vous devez copier et modifier un fichier de configuration GKE On-Prem pour chaque cluster d'utilisateur supplémentaire que vous souhaitez créer.

Avant de commencer

  • Assurez-vous qu'un cluster d'administrateur est en cours d'exécution. Vous avez créé un cluster d'administrateur lors de l'installation de GKE On-Prem.
  • Recherchez le fichier config.yaml généré par gkectl pendant l'installation. Ce fichier définit les spécifications pour le cluster d'administrateur et les clusters d'utilisateur. Vous devez copier et modifier ce fichier pour créer des clusters d'utilisateur supplémentaires.
  • Localisez le fichier kubeconfig du cluster d'administrateur. Vous devez référencer ce fichier lorsque vous copiez et modifiez config.yaml.

Limites

Limite Description
Limites maximale et minimale pour les clusters et les nœuds

Consultez la page Quotas et limites pour en savoir plus. Les performances de votre environnement peuvent avoir un impact sur ces limites.

Unicité pour les noms de cluster d'utilisateur

Tous les clusters d'utilisateur enregistrés dans le même projet Google Cloud doivent avoir des noms uniques.

Impossibilité de déployer sur plusieurs centres de données vCenter et/ou vSphere

Actuellement, vous ne pouvez déployer qu'un cluster d'administrateur et un ensemble de clusters d'utilisateur associés sur un seul centre de données vCenter ou vSphere. Vous ne pouvez pas déployer les mêmes clusters d'administrateur et d'utilisateur sur plusieurs centres de données vCenter ou vSphere.

Impossibilité de modifier de manière déclarative les configurations de cluster après la création Bien que vous puissiez créer des clusters supplémentaires et redimensionner des clusters existants, vous ne pouvez pas modifier un cluster existant via son fichier de configuration.

Vérifier que suffisamment d'adresses IP sont disponibles

Assurez-vous que suffisamment d'adresses IP sont allouées au nouveau cluster d'utilisateur. Vérifier que vous disposez d'un nombre suffisant d'adresses IP dépend du fait que vous utilisiez un serveur DHCP ou des adresses IP statiques.

DHCP

Vérifiez que le serveur DHCP du réseau dans lequel le cluster sera créé possède suffisamment d'adresses IP. Il doit y avoir plus d'adresses IP que de nœuds s'exécutant dans le cluster d'utilisateur.

IP statiques

Vérifiez que vous avez attribué suffisamment d'adresses IP à votre équilibreur de charge et veillez à les indiquer lors de la création de clusters.

Créer une partition F5 BIG-IP

Si vous utilisez F55 BIG-IP pour l'équilibrage des charges, créez une partition pour le nouveau cluster d'utilisateur.

Copier le fichier de configuration

Copiez le fichier de configuration GKE On-Prem que vous avez généré à l'aide de gkectl create-config et modifié en fonction de votre environnement. Renommez la copie pour utiliser un autre nom de fichier :

cp [CONFIG_FILE] [NEW_USER_CLUSTER_CONFIG]

[NEW_USER_CLUSTER_CONFIG] est le nom que vous choisissez pour la copie du fichier de configuration. Dans le cadre de ce document, nous appellerons ce fichier create-user-cluster.yaml.

Dans create-user-cluster.yaml, vous devez modifier les champs suivants :

  • admincluster, qui correspond à la spécification du cluster d'administrateur. Vous devez supprimer complètement la spécification admincluster du fichier.
  • usercluster, qui correspond à la spécification d'un cluster d'utilisateur.

Dans les sections suivantes, vous allez modifier les champs admincluster et usercluster de create-user-cluster.yaml, puis utiliser le fichier pour créer des clusters d'utilisateur supplémentaires.

Supprimer la spécification admincluster

Si vous souhaitez créer des clusters d'utilisateur supplémentaires à partir du cluster d'administrateur existant, vous devez supprimer l'intégralité de la spécification admincluster.

Pour ce faire, il vous suffit de supprimer la spécification ainsi que tous ses sous-champs.

Assurez-vous de ne pas supprimer la spécification usercluster ni aucun de ses sous-champs.

Modifier la spécification usercluster

Modifiez les champs usercluster comme indiqué dans les sections suivantes.

Modifier le nom du cluster d'utilisateur

Modifiez le nom du cluster d'utilisateur dans le champ usercluster.clustername. Les noms des nouveaux clusters d'utilisateur doivent être différents de ceux des clusters d'utilisateur existants.

Réserver des adresses IP pour les nœuds du cluster d'utilisateur

Si vous utilisez le protocole DHCP, assurez-vous que vous disposez de suffisamment d'adresses IP pour que les nœuds puissent être créés.

Pour les adresses IP statiques, vous devez modifier le fichier fourni avec usercluster.ipblockfilepath et contenant les adresses IP prédéfinies du cluster d'utilisateur, ou fournir un autre fichier IP statique YAML avec les adresses IP de votre choix.

Réserver des adresses IP pour l'équilibreur de charge

Si vous utilisez l'équilibreur de charge F5 BIG-IP, veillez à réserver deux adresses IP pour l'entrée et le plan de contrôle de l'équilibreur de charge du cluster d'utilisateur. Les champs correspondants sont usercluster.vips.controlplanevip et usercluster.vips.ingressvip.

Modifier la configuration système requise de machine (facultatif)

Si vous avez besoin que le plan de contrôle ou les nœuds de calcul de ce cluster d'utilisateur utilisent une quantité différente de processeur ou de mémoire, ou si vous avez besoin que le cluster exécute des nœuds supplémentaires ou moins de nœuds, définissez les valeurs des champs suivants :

usercluster.masternode

  • usercluster.masternode.cpus : nombre de cœurs de processeur à utiliser.
  • usercluster.masternode.memorymb : nombre de Mo de mémoire à utiliser.
  • usercluster.masternode.replicas : nombre de nœuds de ce type à exécuter. La valeur doit être 1 ou 3.

usercluster.workernode

  • usercluster.workernode.cpus : nombre de cœurs de processeur à utiliser.
  • usercluster.workernode.memorymd : nombre de Mo de mémoire à utiliser.
  • usercluster.workernode.replicas : nombre de nœuds de ce type à exécuter

Configurer la partition F5 BIG-IP

Si vous utilisez F5 BIG-IP pour l'équilibrage de charge, vous avez précédemment créé une partition pour le nouveau cluster utilisateur. Configurez maintenant la partition dans le champ usercluster.bigip.partition. Exemple :

usercluster:
...
bigip:
  partition: "my-new-user-f5-partition"
...

Créer le cluster d'utilisateur

Maintenant que vous avez renseigné un fichier create-user-cluster.yaml, vous êtes prêt à l'utiliser pour créer un cluster d'utilisateur supplémentaire.

Exécutez la commande suivante :

gkectl create cluster --config create-user-cluster.yaml --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

où :

  • create-user-cluster.yaml est le fichier de configuration que vous venez de créer. Vous avez peut-être choisi un autre nom pour ce fichier.
  • [ADMIN_CLUSTER_KUBECONFIG] pointe vers le kubeconfig du cluster d'administrateur existant.

Dépannage

Pour en savoir plus, consultez la section Dépannage.

Diagnostiquer des problèmes de cluster à l'aide de gkectl

Utilisez les commandes gkectl diagnose pour identifier les problèmes de cluster et partager des informations de cluster avec Google. Consultez la page Diagnostiquer les problèmes de cluster.

Comportement de journalisation par défaut

Pour gkectl et gkeadm, l'utilisation des paramètres de journalisation par défaut est suffisante :

  • Par défaut, les entrées de journal sont enregistrées comme suit :

    • Pour gkectl, le fichier journal par défaut est /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log, et le fichier est lié symboliquement au fichier logs/gkectl-$(date).log dans le répertoire local où vous exécutez gkectl.
    • Pour gkeadm, le fichier journal par défaut est logs/gkeadm-$(date).log dans le répertoire local où vous exécutez gkeadm.
  • Toutes les entrées de journal sont enregistrées dans le fichier journal, même si elles ne sont pas affichées sur le terminal (lorsque --alsologtostderr a la valeur false).
  • Le niveau de verbosité -v5 (par défaut) couvre toutes les entrées de journal requises par l'équipe d'assistance.
  • Le fichier journal contient également la commande exécutée et le message d'échec.

Nous vous recommandons d'envoyer le fichier journal à l'équipe d'assistance lorsque vous avez besoin d'aide.

Spécifier un emplacement autre que celui par défaut pour le fichier journal

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkectl, utilisez l'option --log_file. Le fichier journal que vous spécifiez ne sera pas lié symboliquement au répertoire local.

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkeadm, utilisez l'option --log_file.

Localiser les journaux de l'API Cluster dans le cluster d'administrateur

Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez essayer de la déboguer en inspectant les journaux des contrôleurs de l'API Cluster dans le cluster d'administrateur :

  1. Recherchez le nom du pod des contrôleurs d'API Cluster dans l'espace de noms kube-system, où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Ouvrez les journaux du pod, où [POD_NAME] correspond au nom du pod. Vous pouvez éventuellement utiliser grep ou un outil similaire pour rechercher les erreurs :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager