Comment dépanner un déploiement de services Kubernetes
Pour débugger un déploiement Kubernetes, les équipes IT doivent commencer par suivre les règles de base du dépannage, puis s’intéresser aux plus petits détails pour trouver la cause profonde d’un problème.
Kubernetes est compliqué. Il inclut de nombreux composants et variables qui rendent difficile de comprendre comment, pourquoi et quand quelque chose ne va pas
Avant de paniquer, rappelez-vous les règles fondamentales du dépannage :
- Utilisez les données historiques, comme les logs, et l’observation pour identifier la cause profonde d’un problème.
- Lorsque vous déterminez la cause ou essayez une solution, ne modifiez qu’une seule variable à la fois.
- Avant de faire confiance à une solution, il faut confirmer qu’elle fonctionne dans différentes conditions.
Il est essentiel de comprendre les nombreux composants et commandes d’administration de Kubernetes pour exécuter la première règle avec succès et pour remettre sur la bonne voie les déploiements d’applications et de services liés à la plateforme d’orchestration.
Petit relevé topographique de Kubernetes
Kubectl est le principal outil d’administration des clusters Kubernetes et comprend plus de 30 commandes. La commande kubectl get révèle des informations de base sur une ressource spécifique. Par exemple, kubectl get pods liste les pods disponibles et leur état, tandis que kubectl get services répertorie les applications exécutées comme un service réseau sur un ensemble de pods.
Cependant, il existe une option plus avancée pour le dépannage : kubectl describes pods, également employé comme kubectl describes pod (TYPE/NAME), fournit des détails sur les étiquettes des conteneurs ou des pods, les besoins en ressources, l’état, la disponibilité, le nombre de redémarrages et les événements.
Par exemple, un administrateur trouve que get pods pour une application Nginx montre qu’un pod particulier ne fonctionne pas. L’utilisation de describe pod nginx-app1-1370807587 indique à l’administrateur que le pod n’a pas pu être planifié, en raison de l’insuffisance des ressources disponibles. Ce qui suit est un sous-ensemble de la sortie retournée qui démontre le problème :
Name: nginx-app1-1370807587
Namespace: default
Node: /
Labels: app=nginx,pod-template-hash=1370807587
Status: Pending
ume populated by a Secret)
SecretName: default-token-4bcbi
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
1m 48s 7 {default-scheduler} Warning
FailedScheduling pod (nginx-deployment-1370807587-fz9sd) failed to fit in any node
fit failure on node (kubernetes-node-6ta5): Node didn't have enough resource: CPU, requested: 1000, used: 1420, capacity: 2000
La présence de ressources inadéquates ne sont qu'une des raisons possibles pour lesquelles un pod peut ne pas fonctionner. Un ou plusieurs noeuds hors service ou des problèmes de connectivité avec les répartiteurs de charge internes ou externes peuvent aussi le dysfonctionnement d'un pod.
Vérifier l'état du service
Dans Kubernetes, les applications accessibles de l'extérieur sont exposées comme un service pour définir un ensemble logique de pods et de contrôles d'accès. Les services sont spécifiés par un nom et l'attribut targetPort. Le contrôleur Kubernetes attribue au service une adresse IP de cluster accessible par les proxies Ingress. Les administrateurs peuvent rencontrer un problème lors du déploiement d'une application Kubernetes en créant le pod mais pas le service. Vérifiez l'état du service à l'aide des commandes suivantes :
wget -O- hostnames
kubectl get svc hostnames
Les commandes wget or kubectl pourraient remonter une erreur comme celle-ci :
Resolving hostnames (hostnames)... failed: Name or service not known.
Ou elles peuvent renvoyer ceci :
No resources found.
Error from server (NotFound): services "hostnames" not found
Ces réponses spécifient que Kubernetes n’a pas créé le service. Pour résoudre ce problème, créez et validez le service à l’aide des commandes suivantes. Dans cet exemple, le numéro de port du service est 9090
kubectl expose deployment hostnames --port=80 --target-port=9090
> service/hostnames exposed
kubectl get svc hostname
Déploiement d'applications dans Kubernetes
Kubernetes expose les applications à la manière de services externes peut compliquer le dépannage. Il existe plusieurs couches d’abstraction séparées par des équilibreurs de charge réseau, telles que les suivantes :Kubernetes expose les applications à la manière de services externes peut compliquer le dépannage. Il existe plusieurs couches d’abstraction séparées par des équilibreurs de charge réseau, telles que les suivantes :
- Les nœuds (Nodes) hébergent les conteneurs présents dans un pod. Comme le précise la documentation de Kubernetes, les conteneurs d’un pod communiquent via l’interface de bouclage du nœud (127.0.0.1), tandis que les pods d’un cluster échangent via le réseau interne du cluster de Kubernetes.
- Les services sont des ressources réseau qui exposent une application exécutée dans des pods à des utilisateurs et à d’autres services externes au cluster.
- Un objet Ingress fournit un mappage de la couche application via HTTPS aux services destinés aux usagers externes.Les contrôleurs Ingress répartissent le trafic vers les différents services en utilisant un hébergement virtuel basé sur le nom. Kubernetes open source prend en charge AWS Application Load Balancer, le contrôleur Ingress pour Google Cloud et ceux de Nginx. Des acteurs tiers supportent le proxy Envoy et le maillage de services Istio.
Les configurations de réseau et de service sont souvent la raison pour laquelle une application Kubernetes est inaccessible. Cela peut être dû au fait que l’interface du service ne pointe pas vers un pod et un port. Pour créer un service, vous pouvez entrer la commande kubectl expose. Par exemple, pour bâtir et vérifier une configuration de service pour une application Nginx, utilisez ce qui suit :
kubectl expose deployment/nginx-app1
kubectl describe svc nginx-app1
Dans cet exemple, la réponse de la commande describe est la suivante :
Name: nginx-app1
Namespace: default
Labels: run=nginx-app1
Annotations: <none>
Selector: run=nginx-app1
Type: ClusterIP
IP: 10.0.162.149
Port: <unset> 80/TCP
Endpoints: 10.244.2.5:80,10.244.3.4:80
Session Affinity: None
Events: <none>
Une erreur courante consiste à ne pas faire correspondre l’attribut targetPort d’un service avec le port que le conteneur utilise dans le pod, spécifié comme containerPort. Un problème similaire se produit si le port du service n’est pas configuré correctement dans le contrôleur Ingress.
Examinez les logs
Les composants Kubernetes, tels que kube-apiserver, kube-scheduler, kube-proxy et kubelet, ainsi que les conteneurs, nœuds et applications qui s’exécutent sur Kubernetes, engendrent tous des journaux. Les informations des logs doivent être archivées afin d’être analysées et utilisées pour le dépannage.
Klog est la bibliothèque de journalisation de Kubernetes qui génère des messages pour ses composants système. De nombreux outils collectent des données sur les événements Kubernetes et les examinent, comme kubewatch, Eventrouter et Event Exporter. Ces observateurs de Kubernetes peuvent travailler de concert avec des logiciels de visualisation de logs, comme Grafana ou Kibana.
Sloop, un projet open source développé par Salesforce, visualise les historiques d’événements et les changements d’état des ressources. Il peut être utilisé pour débugger les déploiements Kubernetes. Les caractéristiques principales de Sloop sont les suivantes :
- La possibilité d’inspecter des ressources qui n’existent plus. Contrairement à la période de conservation par défaut d’une heure de Kubernetes, Sloop conserve les événements indéfiniment, de sorte que les administrateurs peuvent voir les pods supprimés ou remplacés.
- Une visualisation de la chronologie qui affiche les déploiements des ressources liées dans les mises à jour des Déploiements, ReplicaSets et StatefulSets. Cette fonctionnalité permet d’identifier les erreurs intermittentes.
- Un service autonome qui fonctionne avec n’importe quel type de stockage.
Le dépannage des déploiements Kubernetes – avec leurs nombreuses couches d’abstraction et leurs paramètres de configuration – nécessite une approche réfléchie. Commencez par les bases, puis remontez la pile logicielle :
- Assurez-vous que tous les pods sont en cours d’exécution. Vérifiez si certains ne parviennent pas à se déployer en raison d’une pénurie de ressources.
- Analysez le flux de trafic interne pour vérifier que les demandes de service arrivent au bon pod.
- Testez le flux de trafic externe à travers un équilibreur de charge réseau et un proxy d’entrée pour valider la configuration du réseau.
- Examinez l’historique des événements avec un outil de visualisation, comme Sloop ou Grafana, pour repérer les anomalies et corriger les problèmes inattendus. Ces étapes aident les administrateurs à déterminer la cause profonde d’une défaillance de service.
