Cette page explique comment créer un cluster d'administrateur pour Anthos clusters on VMware (GKE On-Prem).
Ces instructions sont complètes. Pour une présentation plus courte de la création d'un cluster d'administrateur, consultez la section Créer un cluster d'administrateur (guide de démarrage rapide).
Avant de commencer
Créez un poste de travail d'administrateur.
Obtenir une connexion SSH à votre poste de travail administrateur
Obtenez une connexion SSH à votre poste de travail administrateur.
Rappelez-vous que gkeadm
a activé votre compte de service d'accès au composant sur le poste de travail administrateur.
Effectuez toutes les étapes décrites dans cette rubrique sur votre poste de travail administrateur dans le répertoire d'accueil.
Fichier de configuration des identifiants
Lorsque vous avez utilisé gkeadm
pour créer votre poste de travail administrateur, vous avez rempli un fichier de configuration d'identifiants nommé credential.yaml
. Ce fichier contient le nom d'utilisateur et le mot de passe de votre serveur vCenter.
Fichier de configuration du cluster d'administrateur
Lorsque gkeadm
a créé votre poste de travail administrateur, il a généré un fichier de configuration nommé admin-cluster.yaml
. Ce fichier de configuration vous permet de créer votre cluster d'administrateur.
Remplir votre fichier de configuration
bundlePath
Ce champ est déjà renseigné.
vCenter
La plupart des champs de ce fichier sont déjà renseignés avec les valeurs que vous avez saisies lors de la création de votre poste de travail administrateur. À l'exception du champ dataDisk
que vous devez remplir ici.
network
Décidez comment vous souhaitez que les nœuds de votre cluster obtiennent leurs adresses IP. Vous disposez des options suivantes :
Depuis un serveur DHCP. Définissez
network.ipMode.type
sur"dhcp"
.À partir d'une liste d'adresses IP statiques que vous fournissez. Définissez
network.ipMode.type
sur"static"
, puis créez un fichier de bloc d'adresses IP qui fournit les adresses IP statiques.
Définissez les valeurs des autres champs dans la section network
.
Que vous utilisiez un serveur DHCP ou que vous spécifiez une liste d'adresses IP statiques, vous avez besoin d'un nombre suffisant d'adresses IP pour répondre aux critères suivants :
Trois nœuds dans le cluster administrateur afin d'exécuter le plan de contrôle et les modules complémentaires du cluster d'administrateur.
Un nœud supplémentaire dans le cluster administrateur à utiliser temporairement pendant les mises à niveau.
Pour chaque cluster utilisateur que vous souhaitez créer, un ou trois nœuds du cluster administrateur pour exécuter les composants du plan de contrôle du cluster utilisateur. Si vous souhaitez que le plan de contrôle d'un cluster utilisateur soit hautement disponible (HA), vous avez besoin de trois nœuds dans le cluster d'administrateur pour le plan de contrôle du cluster utilisateur. Sinon, vous n'avez besoin que d'un seul nœud dans le cluster d'administrateur pour le plan de contrôle du cluster d'utilisateur.
Par exemple, supposons que vous souhaitiez créer deux clusters d'utilisateur : l'un avec un plan de contrôle à haute disponibilité et l'autre avec un plan de contrôle sans haute disponibilité. Vous auriez besoin de huit adresses IP pour les nœuds suivants dans le cluster d'administrateur :
- Trois nœuds pour le plan de contrôle et les modules complémentaires du cluster d'administrateur
- Un nœud temporaire
- Trois nœuds pour le plan de contrôle du cluster d'utilisateur à haute disponibilité
- Un nœud pour le plan de contrôle du cluster d'utilisateur sans haute disponibilité
Comme mentionné précédemment, si vous souhaitez utiliser des adresses IP statiques, vous devez fournir un fichier de bloc d'adresses IP. Voici un exemple de fichier de bloc d'adresses IP avec huit hôtes :
blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7 - ip: 172.16.20.17 hostname: admin-host8
loadBalancer
Réservez une adresse IP virtuelle pour le serveur d'API Kubernetes de votre cluster d'administration. Réservez une autre adresse IP virtuelle pour le serveur de modules complémentaires. Indiquez vos adresses IP virtuelles comme valeurs pour loadBalancer.vips.controlPlaneVIP
et loadBalancer.vips.addonsVIP
.
Choisissez le type d'équilibrage de charge que vous souhaitez utiliser. Vous disposez des options suivantes :
Équilibrage de charge groupé Seesaw. Définissez
loadBalancer.kind
sur"Seesaw"
, puis remplissez la sectionloadBalancer.seesaw
.Équilibrage de charge intégré avec F5 BIG-IP Définissez
loadBalancer.kind
sur"F5BigIP"
, puis remplissez la sectionf5BigIP
.Équilibrage de charge manuel. Définissez
loadBalancer.kind
sur"ManualLB"
, puis remplissez la sectionmanualLB
.
antiAffinityGroups
Définissez antiAffinityGroups.enabled
sur true
ou false
en fonction de votre préférence.
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
Choisissez où vous souhaitez conserver les images de conteneurs pour les composants Anthos clusters on VMware. Vous disposez des options suivantes :
gcr.io. Ne remplissez pas la section
privateRegistry
.Votre propre registre Docker privé. Remplissez la section
privateRegistry
.
gcrKeyPath
Définissez gcrKeyPath
sur le chemin d'accès du fichier de clé JSON pour votre compte de service d'accès au composant.
stackdriver
Remplissez la section stackdriver
.
cloudAuditLogging
Si vous souhaitez que les journaux d'audit Kubernetes soient intégrés aux journaux d'audit Cloud, remplissez la section cloudAuditLogging
.
autoRepair
Si vous souhaitez activer la réparation automatique des nœuds, définissez autoRepair.enabled
sur true
. Sinon, définissez cette valeur sur false
.
adminMaster
Si vous souhaitez configurer manuellement les processeurs et la mémoire pour le nœud de plan de contrôle administrateur, remplissez la section adminMaster
.
Valider votre fichier de configuration
Après avoir rempli le fichier de configuration du cluster d'administrateur, exécutez gkectl check-config
pour vérifier que le fichier est valide :
gkectl check-config --config [CONFIG_PATH]
où [CONFIG_PATH] est le chemin d'accès au fichier de configuration de votre cluster d'administrateur.
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 page Exécuter des vérifications préliminaires.
Exécuter gkectl prepare
Exécutez gkectl prepare
pour initialiser votre environnement vSphere :
gkectl prepare --config [CONFIG_PATH]
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.
Si vous utilisez un registre Docker privé, cette commande transfère les images de conteneur Docker vers votre registre.
Cette commande peut éventuellement valider les 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éer un équilibreur de charge Seesaw pour votre cluster d'administrateur
Si vous avez choisi d'utiliser l'équilibreur de charge groupé Seesaw, suivez la procédure dans cette section. Sinon, vous pouvez ignorer cette section.
Créez et configurez la VM pour votre équilibreur de charge Seesaw :
gkectl create loadbalancer --config [CONFIG_PATH]
Créer le cluster d'administrateur
Créez le cluster d'administrateur :
gkectl create admin --config [CONFIG_PATH]
où [CONFIG_PATH] est le chemin d'accès au fichier de configuration de votre 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.
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]
où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig.
Le résultat affiche les nœuds du cluster d'administrateur.
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 fichierlogs/gkectl-$(date).log
dans le répertoire local où vous exécutezgkectl
. -
Pour
gkeadm
, le fichier journal par défaut estlogs/gkeadm-$(date).log
dans le répertoire local où vous exécutezgkeadm
.
-
Pour
- 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 valeurfalse
). - 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 :
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
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, Anthos clusters on VMware génère un fichier kubeconfig nommé internal-cluster-kubeconfig-debug
dans le répertoire d'accueil du 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, Anthos clusters on VMware crée un cluster d'amorçage temporaire. Après une installation réussie, Anthos clusters on VMware 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 la section Dépannage.
Étapes suivantes
Créez un cluster d'utilisateur.