Supervision des conteneurs (Kubernetes et Docker)

Un moniteur URL vous dit qu’une application est lente. Un moniteur workload vous dit pourquoi : le Deployment tourne avec 1 réplica sur 3, un pod est en CrashLoopBackOff, le conteneur a été tué pour dépassement mémoire il y a dix minutes. Mugnsoft lit ces informations directement dans l’apiserver Kubernetes ou l’API Docker Engine, depuis une sonde, sans rien installer dans le cluster.

Le modèle

La supervision des conteneurs suit le même modèle équipement avec enfants que les équipements SNMP et WMI.

Un workload est identifié par ce qui survit à un déploiement, jamais par un nom de pod ou un identifiant de conteneur :

Avant de commencer

Kubernetes : un ServiceAccount en lecture seule

La sonde n’utilise que get et list. Un ClusterRole, plutôt qu’un Role limité à un namespace, permet de laisser Namespace vide et de voir tous les namespaces.

apiVersion: v1
kind: Namespace
metadata: { name: mugnsoft }
---
apiVersion: v1
kind: ServiceAccount
metadata: { name: mugnsoft-probe, namespace: mugnsoft }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: { name: mugnsoft-probe }
rules:
  - apiGroups: [""]
    resources: ["pods", "nodes", "namespaces", "events"]
    verbs: ["get", "list"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets", "daemonsets"]
    verbs: ["get", "list"]
  - apiGroups: ["batch"]
    resources: ["cronjobs", "jobs"]
    verbs: ["get", "list"]
  - apiGroups: ["metrics.k8s.io"]
    resources: ["pods", "nodes"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata: { name: mugnsoft-probe }
roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: mugnsoft-probe }
subjects:
  - { kind: ServiceAccount, name: mugnsoft-probe, namespace: mugnsoft }
---
# Jeton longue durée. Depuis Kubernetes 1.24, un ServiceAccount n'en reçoit plus automatiquement.
apiVersion: v1
kind: Secret
metadata:
  name: mugnsoft-probe-token
  namespace: mugnsoft
  annotations:
    kubernetes.io/service-account.name: mugnsoft-probe
type: kubernetes.io/service-account-token

Appliquez-le, puis récupérez les trois valeurs demandées par le formulaire :

kubectl apply -f mugnsoft-probe.yaml

# Endpoint
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'; echo
# Jeton (une ligne, sans préfixe "Bearer ")
kubectl -n mugnsoft get secret mugnsoft-probe-token -o jsonpath='{.data.token}' | base64 -d; echo
# Certificat CA (PEM)
kubectl -n mugnsoft get secret mugnsoft-probe-token -o jsonpath='{.data.ca\.crt}' | base64 -d

Docker : socket ou endpoint TLS

tcp:// suit la convention Docker : TLS lorsqu’un CA ou un certificat client est renseigné ou que le port est 2376, HTTP simple sinon. N’utilisez un port non chiffré que sur un réseau privé de confiance : c’est un accès root non authentifié à l’hôte.

Ou exécuter la sonde dans le cluster

Une sonde installée dans le cluster avec le chart Helm n’a besoin de rien de ce qui précède : elle utilise son propre ServiceAccount, avec le rôle en lecture seule que crée le chart. Choisissez Auth mode inCluster et laissez Endpoint vide. Voir Installer une sonde sur Kubernetes.

Ajouter un hôte de conteneurs

Ouvrez Container hosts et cliquez sur Ajouter. Le formulaire comporte quatre onglets.

Settings

Connection

Workloads

Cliquez sur Discover & Test (onglet Settings ou Workloads). Le bouton envoie le formulaire tel que saisi, pas l’enregistrement sauvegardé : il sert donc aussi de test de connexion.

OK via probe probe-01
4 workload(s) visible

  default/deployment/web            2/2 ready
  kube-system/deployment/coredns    2/2 ready
  kube-system/daemonset/kube-proxy  3/3 ready
  default/statefulset/pg            1/1 ready

Une ligne ERROR donne la raison : endpoint injoignable, jeton refusé, RBAC manquant, CA inconnu. Une liste vide sous OK signifie que le périmètre ne correspond à rien.

La liste est regroupée par namespace ou projet compose, les conteneurs autonomes en dernier ; la case d’un groupe coche tous ses workloads.

Cocher un workload, c’est décider de l’adopter : son moniteur est créé activé sur chaque sonde sélectionnée à l’enregistrement.

Actions

Les mêmes paramètres de notification qu’un équipement SNMP, appliqués à chaque workload de l’hôte :

Enregistrer l’hôte pousse ces paramètres vers tous ses workloads : une seule modification atteint chaque moniteur workload. Sans Integrator, la sonde envoie elle-même les notifications ; avec un Integrator, c’est lui qui s’en charge. L’email exige que le paramétrage SMTP ait été validé.

Découverte, adoption et dérive

• Ce qui est proposé. Kubernetes : Deployments, StatefulSets, DaemonSets et CronJobs. Les Jobs ne sont pas proposés, car les CronJobs les créent et les suppriment en permanence ; le CronJob lui-même l’est. Docker : conteneurs et services compose. Les conteneurs ponctuels docker compose run sont ignorés.
• Auto-adopt. Toutes les 10 minutes, le Webserver relance la découverte de chaque hôte dont Auto-adopt est activé :
  • un nouveau workload est proposé, jamais adopté : son moniteur est créé désactivé, dans la limite de l’adoption cap ;
  • un workload disparu est marqué « gone » et son moniteur désactivé. Il n’est jamais supprimé, son historique reste consultable, et il conserve votre décision d’adoption s’il revient.
• Une réponse partielle ne retire jamais rien. Si la découverte a été interrompue (un type que le jeton ne peut pas lister, un timeout, un très gros cluster), rien n’est marqué disparu.
• Supprimer un hôte de conteneurs conserve ses moniteurs workload et leur historique. Les retirer est une action explicite sur chaque moniteur.

Évaluation d’un workload

L’échelle de gravité

ERROR se classe au-dessus de CRITICAL, et c’est voulu : « je n’ai pas pu regarder » ne doit jamais se lire « j’ai regardé et tout va bien », et doit rester distinct de « j’ai regardé et c’est mauvais ».

Les règles

Métriques

Chaque contrôle enregistre sept groupes, présentés un panneau par groupe dans le rapport du workload. Chaque clé est écrite à chaque contrôle, à zéro lorsque le runtime n’a pas d’équivalent : un conteneur Docker remonte ainsi les compteurs de phases de pods à 0 plutôt que de laisser des trous dans les séries.

Le temps de réponse tracé pour un workload est la latence de l’API pendant le contrôle, pas celle de l’application.

Où apparaissent les résultats

Le statut propre de l’hôte de conteneurs combine quatre signaux indépendants, parce qu’ils tombent en panne indépendamment : l’endpoint est joignable, l’API répond sainement (/readyz ou /_ping), la pire condition de nœud (Kubernetes uniquement) et le pire workload. Un jeton expiré se lit donc comme un problème d’API plutôt que comme un cluster en panne. Côté nœuds, une pression mémoire, disque ou PID est MINOR, un nœud NotReady MAJOR, aucun nœud prêt CRITICAL, et un nœud cordonné ne relève jamais la gravité : un drainage de maintenance ne réveille personne.

Limites

Dépannage

Voir aussi

• Types de moniteurs — le catalogue de tous les types
• Composant Moniteur en détail — stockage, moteur et endpoints
• Integrator — sorties, ITSM et modèle causal, dont workload
• Évaluation SNMP et WMI — les autres types équipement avec enfants
• Comment fonctionnent les seuils — modèle de gravité et calcul du statut

Traductions

• en: Container monitoring (Kubernetes & Docker)