Version 1.0. Cette version n'est plus compatible, comme indiqué dans la politique de compatibilité avec les versions d'Anthos. Pour obtenir les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant Anthos Clusters on VMware (GKE On-Prem), passez à une version compatible. Vous trouverez la version la plus récente ici.

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.

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.

Dans le fichier copié, vous devrez peut-être modifier le champ suivant :

  • gkeplatformversion, qui spécifie la version de Kubernetes à exécuter dans les clusters. (Il ne s'agit pas de la version de la plate-forme GKE On-Prem. Dans une prochaine release, ce champ sera renommé.)

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

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 fichier 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 des 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