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

Versions disponibles

Dépannage

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.

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 :

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

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

É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 avec proxyconnect 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 ou HTTPS_PROXY. Si https:// 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 et HTTPS_PROXY pour omettre le préfixe https://. Sous Windows, modifiez les variables d'environnement système. Par exemple, remplacez la valeur https://webproxy.example.com:8000 de la variable d'environnement https_proxy par webproxy.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 dans config.yaml, qui a été utilisée pour créer le cluster, contient les champs group et username 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 et user dans la section oidc du fichier config.yaml sont présentes dans id-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 ou groupprefix fourni dans la section oidc du fichier config.yaml.

Notez que si usernameprefix n'est pas spécifié et que username est une valeur autre que email, le préfixe est défini par défaut sur issuerurl#. 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 jeton id_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 erreur Unauthorized 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.

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

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 fichier config.yaml, usehttpproxy doit être défini sur true. 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 remplacez useHTTPProxy par true.
useHTTPProxy est déjà défini sur true.

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 champ capath doit être fourni dans la section oidc du fichier config.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 ajoutez prompt=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

`AccessDeniedException` lors du téléchargement du fichier OVA

Symptômes

La signature renvoie l'erreur suivante lors d'une tentative de téléchargement du fichier OVA du poste de travail administrateur :

AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release

Causes probables

Votre compte de service sur liste d'autorisation n'est pas activé.

Solution

Assurez-vous d'avoir activé votre compte de service sur liste d'autorisation. Si le problème persiste, contactez Google pour obtenir de l'aide.

`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 pas Verified 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 commande kubectl 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.)

Mises à niveau

À 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. Remarque : Si les nœuds du cluster d'utilisateur ne parviennent pas à accéder au plan de contrôle d'utilisateur lors de la mise à niveau, les nouvelles charges de travail ne sont pas planifiées dans le cluster. Les charges de travail existantes ne sont pas affectées.
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.

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 de https://.

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.

Dépannage

Avant de commencer

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

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

Consigner des erreurs gkectl dans stderr

Localiser les journaux gkectl sur le poste de travail administrateur

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

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

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

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

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

Plug-in d'authentification pour Anthos

Échec de l'exécution de gkectl create-login-config

Échec de l'exécution de gcloud anthos auth login

Échec de l'accès au cluster avec le fichier kubeconfig généré par gcloud anthos auth login

Connexion à la console Google Cloud

La connexion redirige l'utilisateur vers une page d'erreur "URL introuvable".

Poste de travail administrateur

AccessDeniedException lors du téléchargement du fichier OVA

openssl ne peut pas valider le fichier OVA du poste de travail administrateur.

Connect

Impossible d'enregistrer un cluster d'utilisateur

L'enregistrement du cluster en version alpha a été annulé

Stockage

Impossible d'associer un volume

Symptômes

Causes probables

Solution

Le volume est perdu.

Symptômes

Causes probables

Solution

Mises à niveau

À propos des temps d'arrêt pendant les mises à niveau

Redimensionner des clusters d'utilisateur

Échec du redimensionnement d'un cluster d'utilisateur

Erreur : "aucune adresse ne peut être allouée"

Un nombre suffisant d'adresses IP est alloué, mais la machine ne parvient pas à s'enregistrer auprès du cluster.

vSphere

Déboguer avec govc

Modifier le certificat vCenter

Divers

Limite de session du fournisseur vSphere Terraform

Utiliser un proxy pour Docker : oauth2: cannot fetch token

Vérifier la validité des licences

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

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

Consigner des erreurs `gkectl` dans `stderr`

Localiser les journaux `gkectl` sur le poste de travail administrateur

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

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

Échec de l'exécution de `gkectl create-login-config`

Échec de l'exécution de `gcloud anthos auth login`

Échec de l'accès au cluster avec le fichier kubeconfig généré par `gcloud anthos auth login`

`AccessDeniedException` lors du téléchargement du fichier OVA

`openssl` ne peut pas valider le fichier OVA du poste de travail administrateur.

Déboguer avec `govc`

Utiliser un proxy pour Docker : `oauth2: cannot fetch token`