Créer un cluster d'utilisateur

Cette page décrit comment créer un cluster d'utilisateur.

Générer un fichier de configuration

Pour créer un cluster d'utilisateur, vous devez disposer d'un fichier de configuration pour le cluster d'utilisateur. Si vous avez utilisé gkeadm pour créer votre poste de travail administrateur, gkeadm a généré un modèle de fichier de configuration et rempli certains champs.

Si vous n'avez pas utilisé gkeadm pour créer votre poste de travail administrateur, vous pouvez générer un modèle en exécutant la commande suivante :

gkectl create-config cluster --config [OUTPUT_PATH]

où [OUTPUT_PATH] est le chemin d'accès de votre choix pour le modèle généré. Si vous n'incluez pas l'option --config, gkectl nomme le fichier user-cluster.yaml et le place dans le répertoire actuel.

Remplir votre fichier de configuration

name

Saisissez le nom de votre choix pour le cluster d'utilisateur dans le champ name.

gkeOnPremVersion

Définissez le champ gkeOnPremVersion.

vCenter

Les valeurs définies dans la section vCenter du fichier de configuration du cluster d'administrateur sont globales. Autrement dit, elles s'appliquent au cluster d'administrateur et aux clusters d'utilisateur.

Pour chaque cluster d'utilisateur que vous créez, vous avez la possibilité de remplacer certaines des valeurs vCenter globales.

Si vous souhaitez remplacer l'une des valeurs vCenter globales, renseignez les champs appropriés dans la section vCenter du fichier de configuration de votre cluster d'utilisateur.

network

Définissez network.ipMode.type sur la même valeur que celle définie dans le fichier de configuration du cluster d'administrateur : "dhcp" ou "static".

Si vous définissez ipMode.type sur "static", créez un fichier de configuration d'hôte qui fournit les adresses IP statiques des nœuds de votre cluster d'utilisateur. Définissez ensuite network.ipBlockFilePath sur le chemin d'accès de votre fichier de configuration d'hôte.

Définissez les valeurs des autres champs dans la section network.

loadBalancer

Définissez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'utilisateur. Définissez-en une autre pour le service d'entrée de votre cluster d'utilisateur. Indiquez vos adresses IP virtuelles comme valeurs pour loadBalancer.controlPlaneVIP et loadBalancer.ingressVIP.

Définissez loadBalancer.kind sur la même valeur que celle définie dans le fichier de configuration du cluster d'administrateur : "ManualLB", "F5BigIP" ou "Seesaw". Renseignez ensuite la section correspondante : manualLB, f5BigIP ou seesaw.

proxy

Si le réseau qui contient les nœuds de votre cluster d'utilisateur se trouve derrière un serveur proxy, renseignez la section proxy.

masterNode

Remplissez la section masterNode.

nodePools

Remplissez la section nodePools.

authentication

Si vous souhaitez authentifier les utilisateurs à l'aide d'OpenID Connect (OIDC), renseignez la section authentication.oidc.

Si vous souhaitez fournir un autre certificat de diffusion pour le serveur vCenter de votre cluster d'utilisateur, renseignez la section authentication.sni.

stackdriver

Remplissez la section stackdriver.

gkeConnect

Remplissez la section gkeConnect.

cloudRun

Définissez cloudRun.enabled sur true ou false.

Valider votre fichier de configuration

Une fois que vous avez rempli le fichier de configuration du cluster d'utilisateur, exécutez gkectl check-config pour vérifier que le fichier est valide :

gkectl check-config --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [CONFIG_PATH]

où :

• [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

• [CONFIG_PATH] est le chemin d'accès au fichier de configuration du cluster d'utilisateur.

Si la commande renvoie des messages d'échec, corrigez les problèmes et validez à nouveau le fichier.

Si vous souhaitez ignorer les validations les plus longues, transmettez l'option --fast. Pour ignorer des validations individuelles, utilisez les options --skip-validation-xxx. Pour en savoir plus sur la commande check-config, consultez la section Exécuter des vérifications préliminaires.

Créer le cluster d'utilisateur

Créez le cluster d'utilisateur :

gkectl create cluster --config [CONFIG_PATH] --skip-validation-all

où [CONFIG_PATH] est le chemin d'accès au fichier de configuration du cluster d'utilisateur.

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

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

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

kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

où [USER_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig.

Le résultat affiche les nœuds du cluster d'utilisateur.

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.

Exécuter des commandes gkectl de manière détaillée

-v5

Consigner des erreurs gkectl dans stderr

--alsologtostderr

Localiser les journaux gkectl sur le poste de travail administrateur

Même si vous ne transmettez pas ses options de débogage, vous pouvez afficher les journaux gkectl dans le répertoire du poste de travail administrateur suivant :

/home/ubuntu/.config/gke-on-prem/logs

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

Résoudre les problèmes F5 BIG-IP à l'aide du fichier kubeconfig du nœud de plan de contrôle du cluster d'administrateur

Après une installation, GKE On-Prem génère un fichier kubeconfig nommé internal-cluster-kubeconfig-debug dans le répertoire d'accueil de votre poste de travail administrateur. Ce fichier kubeconfig est identique à celui de votre cluster d'administrateur, sauf qu'il pointe directement vers le nœud de plan de contrôle du cluster d'administrateur, où s'exécute le plan de contrôle d'administrateur. Vous pouvez utiliser le fichier internal-cluster-kubeconfig-debug pour résoudre les problèmes F5 BIG-IP.

Échec de la validation de gkectl check-config : impossible de trouver les partitions F5 BIG-IP

Symptômes

La validation échoue, car les partitions F5 BIG-IP sont introuvables, même si elles existent.

Causes probables

Un problème avec l'API F5 BIG-IP peut entraîner l'échec de la validation.

Solution

Essayez d'exécuter gkectl check-config à nouveau.

Échec de gkectl prepare --validate-attestations : impossible de valider l'attestation de version

Symptômes

L'exécution de gkectl prepare avec l'option facultative --validate-attestations renvoie l'erreur suivante :

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

Causes probables

Une attestation peut ne pas exister pour la ou les images affectées.

Solution

Essayez à nouveau de télécharger et de déployer le fichier OVA du poste de travail administrateur, comme indiqué sur la page Créer un poste de travail administrateur. Si le problème persiste, contactez Google pour obtenir de l'aide.

Déboguer à l'aide des journaux du cluster d'amorçage

Lors de l'installation, GKE On-Prem crée un cluster d'amorçage temporaire. Après une installation réussie, GKE On-Prem supprime le cluster d'amorçage, vous laissant ainsi votre cluster d'administrateur et votre cluster d'utilisateur. En règle générale, vous ne devriez avoir aucune raison d'interagir avec ce cluster.

Si une erreur se produit lors d'une installation et que vous avez transmis --cleanup-external-cluster=false à gkectl create cluster, il peut être utile d'effectuer un débogage à l'aide des journaux du cluster d'amorçage. Vous pouvez rechercher le pod, puis obtenir ses journaux :

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Pour en savoir plus, consultez Dépannage.