Dépanner le serveur d'API Kubernetes

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

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

Expirations de délai du webhook et appels de webhook ayant échoué

Ces erreurs peuvent être observées de différentes manières. Si vous rencontrez l'un des problèmes suivants, il est possible que les appels webhook échouent:

  • Connexion refusée:si kube-apiserver signale des erreurs d'expiration de délai lors de 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 maximal 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 que vous rencontrez des problèmes de délai avant expiration du webhook ou d'échec d'appels de 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 dans le journal d'éventuelles erreurs liées au réseau, telles que TLS handshake error.
    • Vérifiez si l'adresse IP/le port correspond à ce sur quoi 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:

  • Des règles de pare-feu supplémentaires peuvent être requises pour le webhook. Pour en savoir plus, découvrez comment ajouter des règles de pare-feu pour des cas d'utilisation spécifiques.

  • Si l'exécution du webhook prend plus de temps, vous pouvez configurer une valeur de délai avant expiration personnalisée. La latence des webhooks augmente la latence des requêtes API et doit donc être évaluée le plus rapidement possible.

  • Si l'erreur de webhook bloque la disponibilité du cluster ou si le webhook ne présente aucun danger et atténue la situation, vérifiez s'il est possible de définir temporairement failurePolicy sur Ignore ou de supprimer le webhook en cause.

Latence ou échec d'appel du serveur d'API

Cette erreur peut s'afficher de différentes manières:

  • Erreurs de résolution de noms 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 exécuté 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 imprimer une erreur réseau générique lorsqu'il tente d'appeler 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

  • Latence élevée lors de la connexion au serveur d'API:la connexion au serveur d'API peut réussir, mais les requêtes expirent côté client. Dans ce scénario, le client imprime 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 le même environnement que celui dans lequel 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 détail élevé. Par exemple, une requête GET adressé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 à partir du résultat et exécuter manuellement la requête avec curl. Par exemple, si l'hôte de service obtenu à partir de la sortie précédente était https://192.0.2.1:36917/, vous pouvez envoyer une requête semblable comme suit:

    # 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 de l'échec de la connexion.

    Si la connexion aboutit, mais qu'elle est lente ou expire, cela signifie qu'un serveur d'API est surchargé. Pour vous en assurer, examinez API Server Request Rate dans la console et demandez les métriques de latence dans Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.

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

  • Si une erreur réseau se produit dans le cluster, il peut y avoir un problème avec le plug-in CNI (Container Network Interface). 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 y accèdent en même temps. Un seul client ne peut pas surcharger un serveur d'API en raison de la limitation et de la fonctionnalité Priorité et équité. Examinez la charge de travail pour les aspects suivants:

    • Fonctionne au niveau des pods. Il est plus courant de créer et d'oublier des pods par erreur que les ressources de niveau supérieur.
    • Corrigez le nombre d'instances répliquées en effectuant un calcul erroné.
    • Un webhook qui renvoie la requête en boucle ou qui 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.