Les sections suivantes décrivent les problèmes que vous pouvez rencontrer lors de l'utilisation de GKE On-Prem sur sit et expliquent comment les résoudre.
Avant de commencer
Consultez les sections suivantes avant de commencer à résoudre un problème.
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
Installation
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]
Plug-in d'authentification pour Anthos
Maintenir la CLI gcloud anthos auth
à jour
De nombreux problèmes courants peuvent être évités en vérifiant que les composants de votre installation gcloud anthos auth
sont à jour grâce aux correctifs de la dernière version.
Deux éléments doivent être vérifiés, car la commande gcloud anthos auth
possède une logique dans le composant principal gcloud
et un composant anthos-auth
empaqueté séparément.
-
Composant principal
gcloud
.-
Pour mettre à jour le composant principal
gcloud
, exécutez la commande suivante :gcloud components update
-
Vérifiez que votre installation
gcloud
n'est pas obsolète en exécutant la commande suivante et en vérifiant que la date d'impression est incluse dans les 12 derniers jours.gcloud version
-
-
Composant
anthos-auth
.-
Pour mettre à jour le composant
anthos-auth
, exécutez la commande suivante :gcloud components install anthos-auth
-
Vérifiez que votre installation
anthos-auth
n'est pas obsolète en exécutant la commande suivante et en vérifiant que la version est 1.1.3 ou une version ultérieure.gcloud anthos auth version
-
Installations apt-get
de gcloud
Pour vérifier si votre installation gcloud
est gérée via apt-get
, exécutez la commande gcloud
components update
et recherchez l'erreur suivante :
$ gcloud components update ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: ...
Problème : vous ne pouvez pas effectuer cette action, car le gestionnaire de composants gcloud CLI est désactivé pour cette installation :
Pour les installations gérées via apt-get
, l'exécution des commandes gcloud components
ci-dessus ne fonctionnera pas directement et générera un message d'erreur semblable à celui reproduit ci-dessus. En revanche, l'exécution des commandes gcloud components update
et gcloud components install anthos-auth
affichent les commandes apt-get
spécifiques que vous pouvez exécuter pour mettre à jour l'installation.
Échec de l'exécution de gkectl create-login-config
Problème 1 :
- Symptômes
Lorsque vous exécutez
gkectl create-login-config
, vous rencontrez l'erreur suivante :Error getting clientconfig using [user_cluster_kubeconfig]
- Causes probables
Cette erreur signifie que le fichier kubeconfig transmis à
gkectl create-login-config
n'est pas destiné à un cluster d'utilisateur ou que l'objet ClientConfig CRD n'est pas apparu lors de la création du cluster.- Solution
Exécutez la commande suivante pour vérifier si l'objet ClientConfig CRD se trouve dans le cluster :
kubectl --kubeconfig [user_cluster_kubeconfig] get clientconfig default -n kube-public
Problème 2 :
- Symptômes
Lorsque vous exécutez
gkectl create-login-config
, vous rencontrez l'erreur suivante :error merging with file [merge_file] because [merge_file] contains a cluster with the same name as the one read from [kubeconfig]. Please write to a new output file
- Causes probables
Chaque fichier de configuration de connexion doit contenir des noms de cluster uniques. Si cette erreur s'affiche, le fichier dans lequel vous écrivez les données de configuration de connexion contient un nom de cluster qui existe déjà dans le fichier de destination.
- Solution
Écrivez dans un nouveau fichier
--output
. Veuillez noter les points suivants :- Si
--output
n'est pas fourni, les données de configuration de connexion seront écrites par défaut dans un fichier nommékubectl-anthos-config.yaml
dans le répertoire actuel. - Si
--output
est déjà défini, la commande essaie de fusionner la nouvelle configuration de connexion avec--output
.
- Si
Échec de l'exécution de gcloud anthos auth
login
Problème 1 :
- Symptômes
L'exécution de
login
à l'aide du plug-in d'authentification et du fichier YAML de configuration de connexion généré échoue.- Causes probables
Il y a peut-être une erreur dans les détails de la configuration OIDC.
- Solution
Vérifiez l'enregistrement du client OIDC avec votre administrateur.
Problème 2 :
- Symptômes
Lorsqu'un proxy est configuré pour le trafic HTTPS, l'exécution de la commande
gcloud anthos auth login
échoue avecproxyconnect tcp
dans le message d'erreur. Voici un exemple de type de message susceptible de s'afficher :proxyconnect tcp: tls: first record does not look like a TLS handshake
.- Causes probables
Il peut y avoir une erreur dans les configurations de variables d'environnement
https_proxy
ouHTTPS_PROXY
. Sihttps://
est spécifié dans les variables d'environnement, les bibliothèques clientes HTTP en langage Go peuvent échouer si le proxy est configuré pour gérer les connexions HTTPS à l'aide d'autres protocoles, tels que Sock5.- Solution
Modifiez les variables d'environnement
https_proxy
etHTTPS_PROXY
pour omettre le préfixehttps://
. Sous Windows, modifiez les variables d'environnement système. Par exemple, remplacez la valeurhttps://webproxy.example.com:8000
de la variable d'environnementhttps_proxy
parwebproxy.example.com:8000
.
Échec de l'accès au cluster avec le fichier kubeconfig généré par gcloud anthos auth login
- Symptômes
Erreur "Opération non autorisée"
Si une erreur "Opération non autorisée" s'affiche lorsque vous utilisez le fichier kubeconfig généré par
gcloud anthos auth login
pour accéder au cluster, cela signifie que le serveur d'API ne peut pas autoriser l'utilisateur.- Causes probables
- Les RBAC appropriés sont manquants ou incorrects, ou la configuration OIDC du cluster est erronée.
- Solution
- Pour résoudre le problème, procédez comme suit :
Analysez le jeton
id-token
du fichier kubeconfig.Dans le fichier kubeconfig généré par la commande de connexion, copiez le jeton
id-token
:kind: Config … users: - name: … user: auth-provider: config: id-token: [id-token] …
Suivez la procédure pour installer jwt-cli et exécutez la commande suivante :
jwt [id-token]
Vérifiez la configuration OIDC.
La section
oidc
renseignée dansconfig.yaml
, qui a été utilisée pour créer le cluster, contient les champsgroup
etusername
qui permettent de définir les options--oidc-group-claim
et--oidc-username-claim
dans le serveur d'API. Une fois le serveur d'API présenté avec le jeton, il recherche cette revendication de groupe et de nom d'utilisateur, et vérifie que le groupe ou l'utilisateur correspondant dispose des autorisations appropriées.Vérifiez que les revendications définies pour
group
etuser
dans la sectionoidc
du fichierconfig.yaml
sont présentes dansid-token
.Vérifiez les autorisations RBAC appliquées.
Vérifiez qu'un contrôle RBAC dispose des autorisations appropriées pour l'utilisateur spécifié par la revendication de nom d'utilisateur ou pour l'un des groupes répertoriés sous la revendication de groupe à l'étape précédente. Le nom de l'utilisateur ou du groupe défini dans le contrôle RBAC doit être précédé du préfixe
usernameprefix
ougroupprefix
fourni dans la sectionoidc
du fichierconfig.yaml
.Notez que si
usernameprefix
n'est pas spécifié et queusername
est une valeur autre queemail
, le préfixe est défini par défaut surissuerurl#
. Pour désactiver les préfixes de noms d'utilisateur,usernameprefix
doit être défini sur-
.Pour en savoir plus sur les préfixes d'utilisateur et de groupe, consultez la section Remplir la spécification OIDC.
Notez que le serveur d'API Kubernetes traite actuellement une barre oblique inverse comme un caractère d'échappement. Par conséquent, si le nom de l'utilisateur ou du groupe contient deux barres obliques inverses (
\\
), le serveur d'API les lira comme une seule barre\
lors de l'analyse du jetonid_token
. Par conséquent, le contrôle RBAC appliqué à cet utilisateur ou à ce groupe ne doit contenir qu'une seule barre oblique inverse. Dans le cas contraire, une erreurUnauthorized
peut s'afficher.Exemple :
config.yaml:
oidc: issuerurl: … username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:" ...
id_token:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }
Les contrôles RBAC suivants accordent ces autorisations d'administrateur au cluster d'utilisateur (notez la barre oblique unique dans le champ de nom au lieu d'une double barre oblique) :
Group RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
User RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Vérifiez les journaux du serveur d'API.
Si le plug-in OIDC configuré dans le serveur d'API Kubernetes ne démarre pas correctement, le serveur d'API renvoie une erreur "Opération non autorisée" lorsque le jeton
id-token
lui est présenté. Pour déterminer si le plug-in OIDC a rencontré des problèmes sur le serveur d'API, exécutez la commande suivante :kubectl --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n [user_cluster_name]
- Symptômes
Impossible de se connecter au serveur : Obtenir {DISCOVERY_ENDPOINT} : x509 : certificat signé par une autorité inconnue
- Causes probables
Le jeton d'actualisation du fichier kubeconfig a expiré.
- Solution
Exécutez à nouveau la commande
login
.
Connexion à la console Google Cloud
Voici les erreurs courantes qui peuvent se produire lorsque vous essayez de vous connecter à l'aide de la console Google Cloud :
La connexion redirige l'utilisateur vers une page d'erreur "URL introuvable".
- Symptômes
La console Google Cloud ne parvient pas à atteindre le fournisseur d'identité GKE On-Prem.
- Causes probables
La console Google Cloud ne parvient pas à atteindre le fournisseur d'identité GKE On-Prem.
- Solution
Pour résoudre le problème, essayez la procédure suivante :
-
Définissez
useHTTPProxy
surtrue
.Si le fournisseur d'identité n'est pas accessible via l'Internet public, vous devez activer le proxy HTTP OIDC pour vous connecter à l'aide de la console Google Cloud. Dans la section
oidc
du fichierconfig.yaml
,usehttpproxy
doit être défini surtrue
. Si vous avez déjà créé un cluster et souhaitez activer le proxy, vous pouvez modifier directement l'objet ClientConfig CRD. Exécutez$ kubectl edit clientconfig default -n kube-public
et remplacezuseHTTPProxy
partrue
. useHTTPProxy
est déjà défini surtrue
.Si le proxy HTTP est activé et que cette erreur persiste, cela signifie peut-être qu'un problème s'est produit lors du démarrage du proxy. Pour obtenir les journaux du proxy, exécutez
$ kubectl logs deployment/clientconfig-operator -n kube-system
. Notez que même si votre fournisseur d'identité dispose d'une autorité de certification connue, le champcapath
doit être fourni dans la sectionoidc
du fichierconfig.yaml
pour que le proxy HTTP démarre.Invites d'autorisation du fournisseur d'identité
Si le serveur d'autorisation vous invite à donner votre autorisation et que vous n'avez pas inclus le paramètre supplémentaire
prompt=consent
, cette erreur peut s'afficher. Exécutez$ kubectl edit clientconfig default -n kube-public
et ajoutezprompt=consent
àextraparams
, puis réessayez de vous connecter.Les contrôles RBAC sont mal configurés.
Si vous ne l'avez pas déjà fait, essayez de vous authentifier à l'aide du plug-in d'authentification pour Anthos. Si une erreur d'autorisation se produit également lors de la connexion avec le plug-in, suivez la procédure de dépannage pour résoudre le problème avec le plug-in, puis réessayez de vous connecter via la console Google Cloud.
Essayez de vous déconnecter et de vous reconnecter.
Dans certains cas, si certains paramètres sont modifiés sur le service de stockage, vous devrez peut-être vous déconnecter explicitement. Accédez à la page des détails du cluster, cliquez sur Déconnexion, puis essayez de vous reconnecter.
Poste de travail administrateur
openssl
ne peut pas valider le fichier OVA du poste de travail administrateur.- Symptômes
L'exécution de
openssl dgst
sur le fichier OVA du poste de travail administrateur ne renvoie pasVerified OK
.- Causes probables
Le fichier OVA comporte un problème qui empêche la validation.
- Solution
Essayez à nouveau de télécharger et de déployer le fichier OVA du poste de travail administrateur, comme indiqué dans la section Télécharger le fichier OVA du poste de travail administrateur. Si le problème persiste, contactez Google pour obtenir de l'aide.
Connect
Impossible d'enregistrer un cluster d'utilisateur
Si vous rencontrez des problèmes pour enregistrer des clusters d'utilisateur, contactez Google afin d'obtenir de l'aide.
L'enregistrement du cluster en version alpha a été annulé
Consultez la page Enregistrer un cluster d'utilisateur dans la documentation de Connect.
Vous pouvez également choisir de supprimer et de recréer le cluster.
Stockage
Impossible d'associer un volume
Symptômes
Le résultat de la commande
gkectl diagnose cluster
se présente comme suit :Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status 1 storage errors
Un ou plusieurs pods sont bloqués à l'état
ContainerCreating
avec un avertissement semblable au suivant :Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 6s (x6 over 31s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.
Causes probables
Si un disque virtuel est associé à la mauvaise machine virtuelle, cela peut être dû au problème #32727 dans Kubernetes 1.12.
Solution
Si un disque virtuel est associé à la mauvaise machine virtuelle, vous devrez peut-être le dissocier manuellement :
- Drainez le nœud.
Consultez la page Drainer un nœud en toute sécurité. Vous pouvez inclure les options
--ignore-daemonsets
et--delete-local-data
dans votre commandekubectl drain
. - Mettez la VM hors tension.
- Modifiez la configuration matérielle de la VM dans vCenter pour supprimer le volume.
- Mettez la VM sous tension.
- Dissociez le nœud.
Le volume est perdu.
Symptômes
Le résultat de la commande
gkectl diagnose cluster
se présente comme suit :Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found 1 storage errors
Un ou plusieurs pods sont bloqués à l'état
ContainerCreating
avec un avertissement semblable au suivant :Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 71s (x28 over 42m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/ kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found
Causes probables
Si une erreur "introuvable" s'affiche pour votre fichier VMDK, cela signifie vraisemblablement que le disque virtuel a été définitivement supprimé. Cela peut se produire si un opérateur supprime manuellement un disque virtuel ou la machine virtuelle à laquelle ce disque est associé. Pour éviter cela, gérez vos machines virtuelles comme décrit sur les pages Redimensionner un cluster d'utilisateur et Mettre à jour des clusters.
Solution
Si un disque virtuel a été définitivement supprimé, vous devrez peut-être nettoyer manuellement les ressources Kubernetes associées :
- Supprimez le PVC associé au PV en exécutant la commande
kubectl delete pvc [PVC_NAME].
. - Supprimez le pod associé au PVC en exécutant la commande
kubectl delete pod [POD_NAME].
. - Répétez l'étape 2. (Oui. Consultez le problème Kubernetes 74374.)
Échec de la dissociation du volume CSI vSphere
Symptômes
Si vous constatez que des pods sont bloqués dans la phase
ContainerCreating
avec des avertissementsFailedAttachVolume
, cela peut être dû à un échec de dissociation sur un autre nœud.Exécutez la commande suivante pour rechercher les erreurs de dissociation CSI :
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
Le résultat doit se présenter sous la forme suivante :
NAME DETACH_ERROR csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 Causes probables
Le droit
CNS > Searchable
n'a pas été accordé à l'utilisateur vSphere.Solution
Ajoutez le droit
CNS > Searchable
à votre compte utilisateur vCenter. L'opération de dissociation fait automatiquement l'objet de plusieurs tentatives jusqu'à ce qu'elle aboutisse.Licences
À propos des temps d'arrêt pendant les mises à niveau
Ressource Description Cluster d'administrateur En cas de panne d'un cluster d'administrateur, les plans de contrôle et les charges de travail des clusters d'utilisateur continuent de s'exécuter, sauf s'ils sont affectés par une panne ayant provoqué le temps d'arrêt.
Plan de contrôle du cluster d'utilisateur En règle générale, les plans de contrôle des clusters d'utilisateur ne font pas l'objet de temps d'arrêt significatifs. Cependant, les connexions de longue durée au serveur d'API Kubernetes peuvent être interrompues et doivent être rétablies. Dans ce cas, l'appelant de l'API doit effectuer de nouvelles tentatives jusqu'à ce qu'il établisse une connexion. Dans le pire des cas, le temps d'arrêt peut durer jusqu'à une minute pendant une mise à niveau.
Nœuds de cluster d'utilisateur Si une mise à niveau nécessite une modification des nœuds de cluster d'utilisateur, GKE On-Prem recrée les nœuds de manière progressive et replanifie les pods exécutés sur ces nœuds. Vous pouvez éviter l'impact sur vos charges de travail en configurant des règles PodDisruptionBudgets et d'anti-affinité appropriées.
Le renouvellement des certificats peut être obligatoire avant la mise à niveau du cluster d'administrateur.
Avant de commencer le processus de mise à niveau du cluster d'administrateur, vous devez vous assurer que les certificats de votre cluster d'administrateur sont actuellement valides et les renouveler si ce n'est pas le cas.
Processus de renouvellement du certificat du cluster d'administrateur
Assurez-vous qu'OpenSSL est installé sur le poste de travail administrateur avant de commencer.
Définissez la variable
KUBECONFIG
:KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Remplacez ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG par le chemin absolu du fichier kubeconfig du cluster d'administrateur.
Obtenez l'adresse IP et les clés SSH du nœud maître administrateur :
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
Vérifiez si les certificats ont expiré :
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
Si les certificats ont expiré, vous devez les renouveler avant de mettre à niveau le cluster d'administrateur.
Sauvegardez les anciens certificats :
Il s'agit d'une étape facultative, mais recommandée.
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
Renouvelez les certificats avec kubeadm :
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all
Redémarrez le nœud maître de l'administrateur :
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
Étant donné que le fichier kubeconfig du cluster d'administrateur expire également si les certificats d'administrateur expirent, vous devez sauvegarder ce fichier avant l'expiration.
Sauvegardez le fichier kubeconfig du cluster d'administrateur :
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"Remplacez
client-certificate-data
etclient-key-data
dans kubeconfig parclient-certificate-data
etclient-key-data
dans le fichiernew_admin.conf
que vous avez créé.
Vous devez valider les certificats renouvelés et le certificat de kube-apiserver.
Vérifiez la date d'expiration des certificats :
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"Vérifiez le certificat de kube-apiserver :
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
Redimensionner des clusters d'utilisateur
Échec du redimensionnement d'un cluster d'utilisateur
- Symptômes
Échec d'une opération de redimensionnement sur un cluster d'utilisateur.
- Causes probables
Plusieurs facteurs peuvent entraîner l'échec des opérations de redimensionnement.
- Solution
Si un redimensionnement échoue, procédez comme suit :
Examinez l'état MachineDeployment du cluster pour vérifier s'il y a des événements ou des messages d'erreur :
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
Déterminez s'il existe des erreurs sur les machines nouvellement créées :
kubectl describe machine [MACHINE_NAME]
Erreur : "aucune adresse ne peut être allouée"
- Symptômes
Après avoir redimensionné un cluster d'utilisateur,
kubectl describe machine [MACHINE_NAME]
affiche l'erreur suivante :Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- Causes probables
Il n'y a pas suffisamment d'adresses IP disponibles pour le cluster d'utilisateur.
- Solution
Attribuez des adresses IP supplémentaires au cluster. Supprimez ensuite la machine concernée :
kubectl delete machine [MACHINE_NAME]
Si le cluster est correctement configuré, une machine de remplacement est créée avec une adresse IP.
Un nombre suffisant d'adresses IP est alloué, mais la machine ne parvient pas à s'enregistrer auprès du cluster.
- Symptômes
Le réseau dispose de suffisamment d'adresses allouées, mais la machine ne parvient toujours pas à s'enregistrer auprès du cluster d'utilisateur.
- Causes possibles :
Il y a peut-être un conflit d'adresses IP. L'adresse IP peut être utilisée par une autre machine ou par votre équilibreur de charge.
- Solution
Vérifiez que l'adresse IP de la machine concernée est disponible. En cas de conflit, vous devez le résoudre dans votre environnement.
vSphere
Déboguer avec
govc
Si vous rencontrez des problèmes spécifiques à vSphere, vous pouvez utiliser
govc
pour les résoudre. Par exemple, vous pouvez facilement confirmer les autorisations et l'accès de vos comptes utilisateur vCenter, et collecter les journaux vSphere.Modifier le certificat vCenter
Si vous exécutez un serveur vCenter en mode d'évaluation ou de configuration par défaut, et que celui-ci dispose d'un certificat TLS, ce certificat peut évoluer au fil du temps. Si le certificat a été modifié, vous devez le signaler aux clusters en cours d'exécution :
Récupérez le nouveau certificat vCenter et enregistrez-le dans un fichier :
true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
Désormais, pour chaque cluster, supprimez le fichier ConfigMap contenant le certificat vSphere et vCenter, puis créez un fichier ConfigMap avec le nouveau certificat. Exemple :
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
Supprimez le pod clusterapi-controllers de chaque cluster. Lorsque le pod redémarre, il commence à utiliser le nouveau certificat. Exemple :
kubectl --kubeconfig kubeconfig -n kube-system get pods
kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...
Divers
Limite de session du fournisseur vSphere Terraform
GKE On-Prem utilise le fournisseur vSphere de Terraform pour afficher les VM dans votre environnement vSphere. La limite de session du fournisseur est de 1 000 sessions. La mise en œuvre actuelle ne ferme pas les sessions actives après utilisation. Vous pouvez rencontrer des erreurs 503 si trop de sessions sont en cours d'exécution.
Les sessions sont automatiquement fermées après 300 secondes.
- Symptômes
Si trop de sessions sont en cours d'exécution, vous pouvez rencontrer l'erreur suivante :
Error connecting to CIS REST endpoint: Login failed: body: {"type":"com.vmware.vapi.std.errors.service_unavailable","value": {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is limited to 1000. Existing sessions are 1000.", "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}}, status: 503 Service Unavailable
- Causes probables
Trop de sessions de fournisseur Terraform s'exécutent dans votre environnement.
- Solution
Actuellement, cela fonctionne comme prévu. Les sessions sont automatiquement fermées après 300 secondes. Pour en savoir plus, reportez-vous au problème GitHub #618.
Utiliser un proxy pour Docker :
oauth2: cannot fetch token
- Symptômes
Lorsque vous utilisez un proxy, vous rencontrez l'erreur suivante :
oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
- Causes probables
Vous avez peut-être fourni un proxy HTTPS au lieu d'un proxy HTTP.
- Solution
Dans votre configuration Docker, définissez l'adresse du proxy sur
http://
au lieu dehttps://
.
Vérifier la validité des licences
N'oubliez pas de vérifier que vos licences sont valides, en particulier si vous utilisez des licences d'essai. Des échecs inattendus peuvent se produire si vos licences F5, vos licences vCenter ou vos licences d'hôte ESXi sont arrivées à expiration.
-