Résoudre les problèmes liés au 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.

Délais avant expiration des webhooks et échecs d'appels de webhook

Ces erreurs peuvent être observées 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 appeler le 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 s'afficher 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 d'expiration du délai de 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 des erreurs réseau, telles que TLS handshake error.
- Vérifiez si l'adresse IP ou le port correspond à celui sur lequel le serveur d'API est configuré pour répondre.
Surveillez la latence du webhook en procédant 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.

Examinez les solutions suivantes pour résoudre ce problème :

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 le webhook nécessite plus de temps, vous pouvez configurer un délai avant expiration personnalisé. La latence des webhooks augmente à la latence des requêtes API. Elle doit donc être évaluée le plus rapidement possible.
Si l'erreur du webhook bloque la disponibilité du cluster ou si le webhook est inoffensif pour la suppression et atténue la situation, vérifiez s'il est possible de définir temporairement le failurePolicy sur Ignore ou de supprimer le webhook défaillant.

Échec de l'appel ou latence du serveur d'API

Cette erreur peut se produire de plusieurs manières:

Erreurs de résolution de noms externes: un client externe peut renvoyer des erreurs contenant lookup dans le message, telles que:
```
dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host
```
Cette erreur ne s'applique pas aux clients exécutés dans le cluster. L'adresse IP du service Kubernetes est injectée, donc aucune résolution n'est 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 élevée 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 affiche généralement des messages d'erreur contenant context deadline exceeded.

Si la connexion au serveur d'API échoue complètement, essayez de l'établir dans le même environnement que celui 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:

À 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 envoyée à /healthz ne nécessite généralement aucune authentification:
```
kubectl get -v999 --raw /healthz
```
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 du résultat précédent était https://192.0.2.1:36917/, vous pouvez envoyer une requête similaire 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 première d'un échec de connexion.

Remarque : Vous ne pouvez pas utiliser les commandes ping ou traceroute sur l'adresse IP. Une adresse IP de service Kubernetes n'accepte pas les protocoles ICMP ou autres que ceux définis dans la liste de la ressource de service.

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

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 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 après une recréation ou une reprogrammation de 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 seul client ne peut pas surcharger un serveur d'API en raison d'une limitation et de la fonctionnalité Priorité et équité. Examinez la charge de travail pour les domaines suivants:
- Fonctionne au niveau du pod. Il est plus courant de créer et de supprimer des pods par erreur que des ressources de niveau supérieur.
- Ajustez le nombre d'instances dupliquées via un calcul erroné.
- Webhook qui renvoie la requête sur elle-même ou qui amplifie la charge en créant plus de requêtes qu'il n'en gère.

Étape suivante

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