Résoudre les problèmes liés au serveur d'API Kubernetes

Cette page vous explique comment résoudre les problèmes liés au serveur d'API Kubernetes (kube-apiserver) pour Google Distributed Cloud Virtual for VMware.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Expirations de délai pour le webhook et échecs d'appels webhook

Ces erreurs peuvent apparaître de différentes manières. Si vous rencontrez l'un des symptômes suivants, il est possible que les appels webhook échouent:

  • Connexion refusée:si kube-apiserver signale des erreurs d'expiration de délai pour l'appel du webhook, l'erreur suivante est signalée dans les journaux:

    failed calling webhook "server.system.private.gdc.goog":
failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s":
dial tcp 10.202.1.18:443: connect: connection refused

  • Délai de contexte dépassé:l'erreur suivante peut également être signalée dans les journaux:

    failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post
"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\":
context deadline exceeded"

Si vous pensez rencontrer des problèmes d'expiration du délai d'attente des webhooks ou des échecs d'appels webhook, utilisez l'une des méthodes suivantes pour confirmer le problème:

  • Consultez le journal du serveur d'API pour voir s'il y a un problème de réseau.

    • Recherchez d'éventuelles erreurs liées au réseau dans le journal (par exemple, TLS handshake error).
    • Vérifiez si l'adresse IP/le port correspond à celui sur lequel le serveur d'API est configuré pour répondre.

  • Pour surveiller la latence du webhook, procédez comme suit:

    1. Dans la console, accédez à la page Cloud Monitoring.

      Accéder à la page Cloud Monitoring

    2. Sélectionnez l'Explorateur de métriques.

    3. Sélectionnez la métrique apiserver_admission_webhook_admission_duration_seconds.

Pour résoudre ce problème, consultez les suggestions suivantes:

Latence ou échec de comm. du serveur d'API

Cette erreur peut se produire de différentes manières:

  • Erreurs de résolution de nom externes:un client externe peut renvoyer des erreurs contenant lookup dans le message, par exemple:

    dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host

    Cette erreur ne s'applique pas à un client s'exécutant dans le cluster. L'adresse IP du service Kubernetes est injectée. Aucune résolution n'est donc requise.

  • Erreurs réseau:le client peut afficher une erreur réseau générique lorsqu'il tente de composer le serveur d'API, comme dans les exemples suivants:

    dial tcp 10.96.0.1:443: connect: no route to host
dial tcp 10.96.0.1:443: connect: connection refused
dial tcp 10.96.0.1:443: connect: i/o timeout

  • Connexion au serveur d'API à latence élevée:la connexion au serveur d'API a peut-être abouti, mais les requêtes ont expiré côté client. Dans ce scénario, le client affiche généralement des messages d'erreur contenant context deadline exceeded.

Si la connexion au serveur d'API échoue complètement, essayez de vous connecter dans l'environnement où le client signale l'erreur. Les conteneurs éphémères Kubernetes peuvent être utilisés pour injecter un conteneur de débogage dans les espaces de noms existants comme suit:

  1. À partir de l'emplacement d'exécution du client problématique, utilisez kubectl pour effectuer une requête avec un niveau de verbosité élevé. Par exemple, une requête GET envoyée à /healthz ne nécessite généralement aucune authentification:

    kubectl get -v999 --raw /healthz

  2. Si la requête échoue ou si kubectl n'est pas disponible, vous pouvez obtenir l'URL de la sortie et exécuter la requête manuellement avec curl. Par exemple, si l'hôte de service obtenu à partir du résultat précédent était https://192.0.2.1:36917/, vous pouvez envoyer une requête similaire à celle-ci:

    # Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing
# a local cluster and you trust the connection cannot be tampered.
# The output is always "ok" and thus contains no sensentive information.

curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz

    Le résultat de cette commande indique généralement la cause racine de l'échec de la connexion.

    Si la connexion aboutit, mais qu'elle est lente ou dépasse le délai, cela indique un serveur d'API surchargé. Pour confirmer, dans la console, examinez API Server Request Rate et les métriques de latence des requêtes dans Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.

Pour résoudre ces échecs de connexion ou problèmes de latence, examinez les options de résolution suivantes:

  • Si une erreur réseau se produit dans le cluster, il se peut qu'il y ait un problème avec le plug-in Container Network Interface (CNI). Ce problème est généralement temporaire et se résout de lui-même après la recréation ou la reprogrammation d'un pod.

  • Si l'erreur réseau provient de l'extérieur du cluster, vérifiez si le client est correctement configuré pour accéder au cluster ou générez à nouveau la configuration du client. Si la connexion passe par un proxy ou une passerelle, vérifiez si une autre connexion passant par le même mécanisme fonctionne.

  • Si le serveur d'API est surchargé, cela signifie généralement que de nombreux clients accèdent au serveur d'API en même temps. Un client ne peut pas surcharger un serveur d'API en raison de limitations et de la fonctionnalité Priorité et équité. Examinez la charge de travail en fonction des aspects suivants:

    • Fonctionne au niveau du pod. Il est plus courant de créer et d'oublier par erreur des pods que des ressources de niveau supérieur.
    • Ajustez le nombre d'instances répliquées par un calcul erroné.
    • Un webhook qui renvoie la requête à elle-même ou amplifie la charge en créant plus de requêtes qu'il n'en gère.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.