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.

Cette page est destinée aux administrateurs et opérateurs informatiques qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente, et qui gèrent les alertes et les pages lorsque les objectifs de niveau de service (SLO) ne sont pas atteints ou que les applications échouent. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

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

Délais avant expiration des webhooks et échec des appels de webhooks

Ces erreurs peuvent se présenter de différentes manières. Si vous rencontrez l'un des symptômes suivants, il est possible que les appels de 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 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 de délai ou d'échec des appels de webhook, utilisez l'une des méthodes suivantes pour confirmer le problème :

Vérifiez le journal du serveur d'API pour voir s'il y a un problème de réseau.
- Recherchez dans le journal les erreurs liées au réseau, comme 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 des webhooks, 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.

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 pour s'exécuter, vous pouvez configurer une valeur de délai avant expiration personnalisée. La latence des webhooks s'ajoute à la latence des requêtes d'API. Elle doit donc être évaluée le plus rapidement possible.
Si l'erreur de webhook bloque la disponibilité du cluster ou si le webhook peut être supprimé sans danger et permet d'atténuer la situation, vérifiez s'il est possible de définir temporairement failurePolicy sur Ignore ou de supprimer le webhook concerné par le problème.

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

Cette erreur peut se présenter de différentes 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 à 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 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 imprime 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 où le client problématique s'exécute, utilisez kubectl pour effectuer une requête avec un niveau de verbosité élevé. Par exemple, une requête GET à /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 de la sortie et effectuer 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 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 l'origine d'une connexion ayant échoué.

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 en dehors de la liste définie dans la ressource du service.

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

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

Si une erreur réseau se produit dans le cluster, il est possible que le plug-in CNI (Container Network Interface) présente un problème. Ce problème est généralement temporaire et se résout de lui-même après une recréation ou une reprogrammation du 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 qui passe 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 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 d'oublier des pods par erreur que des ressources de niveau supérieur.
- Ajustez le nombre d'instances répliquées via un calcul erroné.
- Un webhook qui renvoie la requête à lui-même ou amplifie la charge en créant davantage de requêtes qu'il ne peut en gérer.

Étape suivante

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