Dans notre blog précédent , nous avons évoqué la difficulté de capturer tous les diagnostics pertinents lors d’un incident avant d’appliquer un correctif de type « pansement ». L’exemple concret le plus courant est celui d’une application exécutée dans un conteneur et le conteneur est redéployé (peut-être vers une version antérieure ou la même version) simplement pour résoudre le problème immédiat. Pour les entreprises où chaque milliseconde de performance et chaque seconde de disponibilité a des conséquences sur l’expérience client, ces types de correctifs à court terme sont une nécessité. Les coûts pour l’entreprise deviennent toutefois importants lorsque les ingénieurs sont chargés de développer le long terme solution à ces incidents. Qu'il s'agisse d'incidents majeurs ou mineurs (récurrents), les ingénieurs doivent consacrer un temps considérable à la collecte de preuves de l'état de l'application et de l'environnement au moment de l'incident.

Bien qu'une bonne partie de ces données de diagnostic réside dans des outils de surveillance et persiste donc, il est parfois nécessaire d'obtenir un shell dans un conteneur pour récupérer des informations qui ne sont disponibles que pendant la durée de vie du conteneur. Dans Kubernetes, cela se fait à l'aide de Exécution de kubectl commande. Avec les bons paramètres, les utilisateurs peuvent obtenir un shell en direct dans leur conteneur en cours d'exécution et commencer à exécuter des commandes pour récupérer des diagnostics. Par exemple, une fois qu'un utilisateur a un shell dans un conteneur Java, il peut invoquer pile j pour obtenir un thread dump de leur application.

Mais de nombreuses équipes opérationnelles ne laissent pas n'importe qui exécutif Les incidents critiques sont souvent traités dans des modules de production (où se produisent les incidents critiques) ou le nombre de personnes qui peuvent le faire est très limité, à la fois pour des raisons de sécurité et en raison du nombre limité de personnes familiarisées avec Kubernetes. Par conséquent, pour récupérer les données de diagnostic lors d'un incident, des personnes disposant d'un accès et d'une expertise Kubernetes doivent régulièrement être appelées à l'aide. Ce processus augmente le coût des incidents en augmentant le MTTR, ainsi que le nombre de personnes qui doivent être impliquées.

Pour ces raisons, il est préférable d’utiliser une automatisation qui élimine la nécessité pour les utilisateurs de exécutif dans des pods en cours d'exécution. Avec cette architecture d'automatisation, lorsqu'un problème survient, un runbook automatisé est invoqué et ce runbook récupère les données de débogage, les envoie à un emplacement de stockage persistant (S3, Blob Storage, serveur SFTP, etc.), puis informe les ingénieurs où ils peuvent localiser et utiliser les données de débogage.

PagerDuty Process Automation fournit un runbook prédéfini et modélisé exactement pour ce cas d'utilisation : lorsqu'une alerte crée un incident dans PagerDuty, cela peut automatiquement (ou par un clic sur un bouton) déclencher le runbook pour exécuter des commandes dans le pod, envoyer le sortie vers un stockage persistant et fournir des détails sur l’emplacement de ces données dans l’incident.

Un lien vers les données de débogage est fourni aux ingénieurs pendant et après l'incident

Les utilisateurs de nos deux produits d'automatisation commerciale ( Automatisation des processus et automatisation des dossiers d'exploitation ) et open source Pont roulant peut suivre les instructions ici pour télécharger et démarrer avec le runbook automatisé.

Ce livre d'exécution automatisé est idéal lorsque l'image du conteneur dispose déjà des utilitaires de ligne de commande (binaires) nécessaires au débogage. Par exemple, de nombreuses applications Java conteneurisées sont fournies avec le pile j utilitaire dans l'image du conteneur ; cependant, que se passe-t-il lorsque les utilitaires de débogage ne sont pas fournis avec l'image du conteneur ? Ou, comme c'est de plus en plus courant, que se passe-t-il lorsque le conteneur est « sans distribution » et ne fournit donc même pas de shell ?

C'est ici que Conteneurs éphémères Kubernetes entre en jeu : fournir aux utilisateurs un mécanisme pour attacher un conteneur (de n'importe quelle image) à un pod en cours d'exécution sans avoir besoin de modifier la définition du pod ou de redéployer le pod.

En partageant l'espace de noms du processus, le conteneur éphémère peut utiliser ses utilitaires de débogage pour un autre conteneur du pod, même si le conteneur d'origine est en panne. Voici un exemple Blog par Ivan Velichko qui entre dans les détails du partage d'espace de noms de processus avec des conteneurs éphémères :

Source : https://iximiuz.com/fr/posts/conteneurs-ephemeres-kubernetes/

Similaire à l'utilisation Exécution de kubectl , l'exploitation correcte des conteneurs éphémères nécessite toujours l'accès à l'exécution kubectl commandes sur le cluster Kubernetes, qui sont rarement disponibles pour les opérations extérieures. Et comme auparavant, savoir comment construire correctement la commande nécessite un niveau de familiarité supérieur avec Kubernetes :

kubectl debug -it -n ${namespace} -c debugger --image=busybox --share-processes ${pod_name}
(Exemple de commande pour l'utilisation des conteneurs éphémères Kubernetes)

Pour répondre aux besoins des utilisateurs qui ont des conteneurs sans utilitaires de débogage ou des conteneurs sans distribution, nous avons créé un nouveau plugin Kubernetes qui exploite la fonctionnalité des conteneurs éphémères :

Nous avons utilisé ce plug-in dans un modèle pour un livre d'exécution automatisé qui capture également la sortie de diagnostic et envoie la sortie vers un emplacement persistant. Les utilisateurs de Process Automation et Runbook Automation peuvent commencer à utiliser ce modèle de travail en le téléchargeant dans le cadre du projet de diagnostic automatisé ici .

Si vous n'avez pas encore de compte Process Automation ou Runbook Automation, cliquez sur ici pour démarrer avec les produits d'automatisation de PagerDuty.