core dump handler
v9.0.0
Ce graphique de barre est conçu pour déployer des fonctionnalités qui enregistrent automatiquement les core dumps de la plupart des fournisseurs de services Kubernetes de cloud public et des instances Kubernetes privées sur un service de stockage compatible S3.
Veuillez lire le CONTRIBUTING.md, il contient quelques notes importantes. Portez une attention particulière aux directives de style de codage et au certificat d'origine du développeur.
En tant que membres, contributeurs et dirigeants, nous nous engageons à faire de la participation à notre communauté une expérience sans harcèlement pour tous, quels que soient l'âge, la taille, le handicap visible ou invisible, l'origine ethnique, les caractéristiques sexuelles, l'identité et l'expression de genre, le niveau d'expérience, l'éducation. , le statut socio-économique, la nationalité, l'apparence personnelle, la race, la religion ou l'identité et l'orientation sexuelles.
Nous nous engageons à agir et à interagir de manière à contribuer à une communauté ouverte, accueillante, diversifiée, inclusive et saine.
Le code de conduite complet est disponible ici
Veuillez vous référer au graphique README.md pour plus de détails.
Il s'agit d'une matrice de cibles de test confirmées. S'il vous plaît, des environnements de relations publiques qui sont également connus pour fonctionner
| Fournisseur | Produit | Version | Validé ? | Fonctionnement? |
| AWS | EKS | 1.21 | Oui | Oui |
| AWS | ROSE | 4.8 | Oui | Oui |
| Construction personnalisée | K8S | N / A | Oui | Oui |
| Océan numérique | K8S | 1.21.5-do.0 | Oui | Oui |
| GKE-cos_containerd | 1.20.10-gke.1600 | Oui | Oui | |
| GKE-Ubuntu | 1.20.10-gke.1600 | Oui | Oui | |
| IBM | IKS | 1.19-1.21 | Oui | Oui |
| IBM | ROKS | 4.6-4.8 | Oui | Oui |
| Microsoft | AK | 1.19 | Oui | Oui |
| Microsoft | BRA | 4.8 | Oui | Oui |
| Chapeau Rouge | Sur site | 4.8 | Oui | Oui |
Les Core Dumps sont un élément essentiel de l’observabilité.
À mesure que les systèmes deviennent de plus en plus distribués, les core dumps offrent aux équipes une approche non invasive pour comprendre pourquoi les programmes fonctionnent mal dans n'importe quel environnement dans lequel ils sont déployés.
Les Core Dumps sont utiles dans un grand nombre de scénarios mais ils sont très pertinents dans les cas suivants :
Le processus se termine sans trace de pile utile
Le processus manque de mémoire
Une application ne se comporte pas comme prévu
Les problèmes traditionnels liés aux core dumps sont :
Frais généraux de gestion des dumps
L'analyse des vidages nécessitait des outils spécifiques qui n'étaient pas facilement disponibles sur la machine des développeurs.
Gérer l'accès aux dumps car ils peuvent contenir des informations sensibles.
Ce graphique vise à résoudre les problèmes liés aux core dumps en exploitant les plates-formes communes (K8, ROKS et Object Storage) dans un environnement cloud pour prendre en charge le gros du travail.
Le graphique déploie deux processus :
L' agent gère la mise à jour de la configuration /proc/sys/kernel/* , déploie le service composer et télécharge le fichier zip des core dumps créé par le composer vers une instance de stockage d'objets.
Le compositeur gère le traitement d'un core dump, la création de documents d'exécution, de coredump de conteneur et d'image JSON à partir de CRICTL et leur insertion dans un seul fichier zip. Le fichier zip est stocké sur le système de fichiers local du nœud pour que l'agent puisse le télécharger.
Lorsque vous installez la charte Helm IBM Cloud Core Dump Handler, les ressources Kubernetes suivantes sont déployées dans votre cluster Kubernetes :
Espace de noms : un espace de noms spécifique est créé pour installer les composants - la valeur par défaut est ibm-observe
Handler Daemonset : Le démonset déploie un pod sur chaque nœud de travail de votre cluster. Le jeu de démons contient une configuration permettant au processus élevé de définir le modèle de base pour placer le vidage de mémoire dans le stockage d'objets ainsi que de collecter les informations de pod si disponibles.
Politique de privilèges : le jeu de démons configure le nœud hôte afin que les privilèges soient requis.
Compte de service : compte de service standard pour exécuter le jeu de démons
Réclamations de volume : pour copier le compositeur sur l'hôte et permettre l'accès aux vidages de mémoire générés
Rôle de cluster : créé avec une ressource d'événement et un verbe de création et associé au compte de service.
Pour installer la charte Helm dans votre cluster, vous devez disposer du rôle de plateforme Administrateur .
Ce graphique déploie un ensemble de démons Kubernetes privilégiés avec les implications suivantes :
la création automatique d'un conteneur privilégié par nœud Kubernetes capable de lire les fichiers principaux en interrogeant le crictl pour obtenir des informations sur le pod.
Le jeu de démons utilise la fonctionnalité hostpath qui interagit avec le système d'exploitation Linux sous-jacent.
Le binaire composer est déployé et exécuté sur le serveur hôte
Les vidages de mémoire peuvent contenir des données d'exécution sensibles et l'accès au bucket de stockage doit être géré en conséquence.
Les clés de stockage d'objets sont stockées sous forme de secrets et utilisées comme variables d'environnement dans le jeu de démons.
Le gestionnaire IBM Cloud Core Dump nécessite les ressources suivantes sur chaque nœud travailleur pour s'exécuter correctement :
$ helm delete core-dump-handler --namespace observe
host-name sont supprimés avant de continuer. $ kubectl get pvc -n observe
$ helm install core-dump-handler . --namespace observe
helm delete core-dump-handler -n observe
Créez le docker build -t YOUR_TAG_NAME .
Transférer l'image vers votre registre de conteneurs
Mettez à jour le conteneur dans le fichier values.yaml pour l'utiliser.
image :
registry : YOUR_REGISTRY
repository : YOUR_REPOSITORY
tag : YOUR_TAGou exécutez la commande helm install avec les paramètres
--set image.registry=YOUR_REGISTRY
--set image.repository=YOUR_REPOSITORY
--set image.tag=YOUR_TAG
Les services sont écrits en Rust en utilisant rustup.
Les tests unitaires locaux peuvent être exécutés à l'aide cargo test dans le dossier de base
Actuellement, seuls IBM Cloud ROKS et IKS sont pris en charge, mais nous sommes heureux d'effectuer des tests d'intégration pour d'autres services, mais nous ne pouvons pas les exécuter avant la publication.
Pour exécuter la build des tests d'intégration, suivez les instructions pour une build personnalisée
À la racine du dossier du projet, créez un fichier appelé .env avec la configuration suivante
S3_ACCESS_KEY=XXXX
S3_SECRET=XXXX
S3_BUCKET_NAME=XXXX
S3_REGION=XXXX
Changez de répertoire pour le dossier d'intégration et exécutez le test
cd integration
./run-ibm.sh
Les versions sont construites sur une branche de pré-version, par exemple les tests d'intégration pre-8.5.0 sont exécutés manuellement et une version est générée lors de la fusion avec la version principale.
Il n'est actuellement pas possible d'automatiser cela car l'intégration de Kubernetes dans les actions github n'est pas suffisamment fiable.
Si vous souhaitez tester une pré-version avec vos propres tests d'intégration, veuillez soulever un problème et nous pourrons collaborer sur votre exécution de test.
Le premier endroit où rechercher les problèmes se trouve dans la console de l'agent. Une installation réussie devrait ressembler à ceci
[2021-09-08T22:28:43Z INFO core_dump_agent] Setting host location to: /var/mnt/core-dump-handler
[2021-09-08T22:28:43Z INFO core_dump_agent] Current Directory for setup is /app
[2021-09-08T22:28:43Z INFO core_dump_agent] Copying the composer from ./vendor/default/cdc to /var/mnt/core-dump-handler/cdc
[2021-09-08T22:28:43Z INFO core_dump_agent] Starting sysctl for kernel.core_pattern /var/mnt/core-dump-handler/core_pattern.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created Backup of /var/mnt/core-dump-handler/core_pattern.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Starting sysctl for kernel.core_pipe_limit /var/mnt/core-dump-handler/core_pipe_limit.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created Backup of /var/mnt/core-dump-handler/core_pipe_limit.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Starting sysctl for fs.suid_dumpable /var/mnt/core-dump-handler/suid_dumpable.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created Backup of /var/mnt/core-dump-handler/suid_dumpable.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created sysctl of kernel.core_pattern=|/var/mnt/core-dump-handler/cdc -c=%c -e=%e -p=%p -s=%s -t=%t -d=/var/mnt/core-dump-handler/core -h=%h -E=%E
kernel.core_pattern = |/var/mnt/core-dump-handler/cdc -c=%c -e=%e -p=%p -s=%s -t=%t -d=/var/mnt/core-dump-handler/core -h=%h -E=%E
kernel.core_pipe_limit = 128
[2021-09-08T22:28:43Z INFO core_dump_agent] Created sysctl of kernel.core_pipe_limit=128
fs.suid_dumpable = 2
[2021-09-08T22:28:43Z INFO core_dump_agent] Created sysctl of fs.suid_dumpable=2
[2021-09-08T22:28:43Z INFO core_dump_agent] Creating /var/mnt/core-dump-handler/.env file with LOG_LEVEL=info
[2021-09-08T22:28:43Z INFO core_dump_agent] Executing Agent with location : /var/mnt/core-dump-handler/core
[2021-09-08T22:28:43Z INFO core_dump_agent] Dir Content []
Si l'agent s'exécute correctement, il se peut qu'il y ait un problème avec la configuration du composeur. Pour vérifier les journaux du composer, ouvrez un shell dans l'agent et lancez le fichier composer.log pour voir s'il y a des messages d'erreur.
cat /var/mnt/core-dump-handler/composer.log
S'il n'y a pas d'erreurs, vous devez modifier le journal par défaut error en debug dans le fichier values.yaml et redéployer le graphique. Créez à nouveau un core dump et /var/mnt/core-dump-handler/composer.log devrait contenir des détails spécifiques sur chaque téléchargement.
