Photo de Marta Sher via Shutterstock
Dans la gestion d'applications moderne, Kubernetes constitue le socle de l'orchestration de conteneurs. Il automatise le déploiement, la mise à l'échelle et la gestion des logiciels, révolutionnant ainsi leur livraison. Toutefois, sa complexité et son envergure croissantes posent de réels défis lorsqu'il s'agit de dépanner et de maintenir des écosystèmes dynamiques.
Le dépannage de Kubernetes est complexe pour de multiples raisons. L'architecture d'un cluster Kubernetes repose sur de nombreux composants qui fonctionnent de concert : pods, services, configurations et réseau. Ces composants interagissent souvent de manière imprévisible, ce qui rend difficile l'identification de la cause racine d'un incident.
Les workloads Kubernetes évoluent également en permanence pour s'adapter aux besoins changeants, ce qui engendre des problèmes transitoires difficiles à diagnostiquer en temps réel. Les méthodes de dépannage traditionnelles reposent sur une investigation manuelle : examen des logs, des métriques et des configurations à travers les différents composants. Le processus est chronophage et propice aux erreurs.
C'est ici qu'interviennent les playbooks interactifs de Google Kubernetes Engine (GKE). En proposant un guide structuré et pas à pas pour les problèmes les plus courants, ces nouveaux playbooks accélèrent la résolution des incidents et améliorent le Mean Time to Resolution (MTTR).
Les playbooks sont disponibles dans les dashboards de monitoring GCP et s'ajoutent automatiquement dès le déploiement du premier workload sur le cluster. Vous trouverez ci-dessous la liste des playbooks interactifs disponibles ; consultez les notes de version GKE pour découvrir les nouveautés.
Capture d'écran depuis GCP Monitoring -> Dashboards
Le playbook interactif s'appuie sur les données de cloud monitoring et de cloud logging : veillez donc à ne pas avoir désactivé la collecte des logs pour les workloads d'un cluster GKE Standard (activée par défaut sur les clusters Autopilot).
Le playbook interactif en pratique
- Déployez sur le cluster un workload défectueux qui ne démarre pas en raison d'un problème de configuration.
kubectl run sample-app --image simbu1290/gke-faulty-app:latest
- Vérifiez l'état du workload dans la console.
État du workload
- Cliquez sur le statut
CrashLoopBackOffde l'application d'exemple : un écran s'ouvre avec des informations complémentaires. Dans la section des recommandations apparaît le playbook interactif associé à l'erreur.
- Cliquez sur
View Interactive Playbookpour accéder au dashboard du playbook dans GCP Monitoring. Vous y trouverez davantage de détails sur l'erreur ainsi que les étapes suivantes pour en identifier la cause racine probable.
Vue d'ensemble du playbook interactif
Erreur de l'application d'exemple affectant le démarrage du conteneur
Les options out-of-memory et liveness probe disponibles dans le dashboard permettent également d'identifier rapidement d'autres causes d'échec. La fonction Correlate Change Events permet de vérifier en un clin d'œil si un déploiement récent a pu impacter votre workload. Vous pouvez ensuite comparer les versions actuelle et précédente afin d'identifier l'origine du problème.
Ce dashboard est personnalisable : vous pouvez ajouter ou retirer des composants selon vos besoins. Si vous utilisez GCP Alerting, vous pouvez créer des alertes depuis la section Future Mitigation Tips.
Exemple de configuration d'une règle d'alerte par e-mail
Le workload concerné et le lien vers le dashboard interactif sont inclus dans la notification d'alerte, ce qui vous permet de démarrer le dépannage sans délai.
Exemple de notification d'alerte par e-mail
En résumé, avec ces playbooks interactifs recommandés, l'équipe GKE entend simplifier le dépannage des incidents les plus courants et, in fine, maximiser la productivité. Si les playbooks interactifs de GKE offrent un cadre précieux pour structurer le dépannage, certaines situations exigent toujours l'intervention d'un expert humain spécialisé.