Surveiller une grappe Kubernetes

Ce que vous saurez

• Chaque application est en service : chaque Deployment, StatefulSet et DaemonSet d’un espace de noms a tous ses pods prêts ; sinon, vous savez lesquels sont incomplets et de combien.
• Les nœuds sont prêts, et aucun ne manque de mémoire, d’espace disque ou d’identifiants de processus.
• Rien ne plante en boucle ni ne reste bloqué faute de pouvoir récupérer son image, et rien ne redémarre toutes les quelques minutes.
• Chaque CronJob réussit à l’heure prévue, et aucun n’est resté suspendu.
• La grappe répond de l’intérieur comme de l’extérieur : un Service par son nom dans la grappe, et votre adresse publique avec son certificat.

Un seul agent s’en charge : il s’exécute dans la grappe sous forme de pod et interroge l’API de la grappe elle-même, là où Kubernetes conserve toute cette information. C’est lui qui se connecte à Gryphon : la grappe n’a besoin d’aucun Service, Ingress ou port ouvert pour lui.

Ce que cette configuration ne peut pas vous dire : la charge des nœuds. Il n’y a pas encore de mesures de processeur ni de mémoire pour une grappe. Et un pod n’est prêt que dans la mesure où sa sonde de disponibilité (readiness probe) le dit : un conteneur sans sonde est prêt dès qu’il démarre, qu’il fonctionne ou non. La vérification HTTP de l’étape 5 répond à ce problème.

Avant de commencer

• Un compte Gryphon au forfait Pro ou Teams. Les vérifications Kubernetes ne font pas partie du forfait Watch.
• kubectl, pointé vers la grappe, avec un utilisateur qui peut créer un espace de noms et un ClusterRole. Sans droits sur toute la grappe, voyez Un espace de noms à la fois.
• La grappe capable de joindre Gryphon en HTTPS, comme n’importe quel site Web.

Les exemples surveillent une application dans un espace de noms appelé shop, avec un Deployment appelé web et un CronJob de nuit appelé backup. Utilisez vos propres noms.

Étapes

1Ajouter la grappe comme hôte

Dans Gryphon, ouvrez Hôtes et choisissez Ajouter un hôte. Un hôte correspond à une grappe, peu importe son nombre de nœuds, et compte pour un seul hôte dans votre forfait.

• Type : Une grappe Kubernetes.
• Nom de l’hôte : le nom que vous lui donnez, comme Grappe de production.
• Adresse publique (facultatif) : l’Ingress ou le répartiteur de charge placé devant, comme shop.example.com. Laissez ce champ vide si rien dans la grappe n’est public.

2Installer l’agent dans la grappe

Sur la page de l’hôte, sous Agent, choisissez Connecter un agent. Un jeton s’affiche, une seule fois, avec les commandes à exécuter :

kubectl create namespace gryphon
kubectl -n gryphon create secret generic gryphon-agent-token --from-literal=token=<token>
kubectl apply -f https://github.com/gocodedotca/gryphon-agent/releases/download/v<version>/gryphon-agent.yaml

La boîte de dialogue remplit le jeton et la version. Le manifeste exécute un pod dans l’espace de noms gryphon, sous un utilisateur sans privilèges, sur un système de fichiers en lecture seule. Son compte peut lire et lister les nœuds, les espaces de noms, les pods et les charges de travail, et rien d’autre : aucun Secret, aucun ConfigMap, aucun journal, aucun exec, aucune modification. Lisez le manifeste avant de l’appliquer ; il est court.

En quelques secondes, la page de l’hôte affiche Connecté et indique la version de la grappe et le nœud sur lequel se trouve l’agent. Sinon :

kubectl -n gryphon get pods
kubectl -n gryphon logs deployment/gryphon-agent

Exécutez un seul agent par grappe, et laissez son Deployment à une seule réplique. Deux agents avec le même jeton remplacent tour à tour la connexion l’un de l’autre, et la page de l’hôte signale que le jeton est utilisé sur plus d’une machine.

3Surveiller les nœuds et l’application

Allez dans Services, choisissez Ajouter le service et sélectionnez Kubernetes : nœuds :

Un nœud qui n’est pas prêt, ou qui manque de mémoire, d’espace disque ou d’identifiants de processus, est un avertissement ; aucun nœud prêt est un problème. Un nœud que vous avez isolé (cordon) pour le vider est nommé, mais ne donne pas d’avertissement. Pour surveiller un groupe de nœuds à part, indiquez son étiquette, comme cloud.google.com/gke-nodepool=default-pool sur GKE ou eks.amazonaws.com/nodegroup=workers sur EKS.

Puis l’application, en une seule vérification :

Elle compte chaque Deployment, StatefulSet et DaemonSet de l’espace de noms. Tous avec tous leurs pods prêts, c’est en bon état ; aucun avec un seul pod prêt, c’est un problème ; entre les deux, c’est un avertissement qui nomme ce qui manque, comme deployment/web 1/3. Un espace de noms qui contient plusieurs applications peut être divisé avec un sélecteur : app.kubernetes.io/part-of=shop, ou app.kubernetes.io/instance=shop pour une version Helm. Un sélecteur qui ne correspond à rien est un problème : une faute de frappe ne passe pas pour une application en bon état.

Pour la charge de travail la plus importante, ajoutez une vérification à part, pour qu’elle ait son propre historique et ses propres alertes :

Les répliques prêtes, comparées à celles demandées : toutes prêtes, c’est en bon état ; quelques-unes, un avertissement ; aucune, un problème ; ramenée à 0, un avertissement. Un déploiement que Kubernetes a abandonné est un avertissement, même pendant que les anciennes répliques servent encore.

4Repérer les plantages en boucle et les CronJobs manqués

Un conteneur qui ne peut pas démarrer — CrashLoopBackOff, une image qu’il ne peut pas récupérer, un Secret introuvable — est un problème, tout comme un conteneur qui a échoué et a été redémarré. Un conteneur qui a redémarré plus de 5 fois, la dernière fois dans l’heure, est un avertissement. Les redémarrages de la semaine dernière ne comptent plus une fois que le pod tourne sans erreur depuis.

Elle lit l’horaire du CronJob, dans son propre fuseau horaire, ainsi que sa dernière réussite. Une exécution planifiée qui n’a pas réussi est un avertissement ; deux de suite sont un problème ; une exécution encore en cours n’est pas en retard. Un CronJob resté suspendu est un problème, car il ne s’exécutera plus jamais tant que quelqu’un ne l’aura pas remarqué.

5Vérifier qu’elle répond, de l’intérieur comme de l’extérieur

Prêt ne veut pas dire fonctionnel. La vérification HTTP de l’agent s’exécute depuis son pod : elle peut donc interroger un Service par son nom dans la grappe :

Pas 127.0.0.1 : dans un pod, c’est l’adresse de l’agent lui-même, et Gryphon la refuse. Si l’hôte a une adresse publique, ajoutez aussi HTTPS et Certificat SSL. Ces vérifications partent de Gryphon, de l’extérieur, vers l’Ingress : elles repèrent ce que la grappe ne peut pas voir d’elle-même, soit le DNS, le répartiteur de charge et un certificat sur le point d’expirer.

Variantes

Un espace de noms à la fois

Si vous ne pouvez pas créer de ClusterRole, utilisez plutôt le manifeste par espace de noms de la même version, et accordez à l’agent chacun des espaces de noms qu’il doit surveiller :

kubectl apply -f https://github.com/gocodedotca/gryphon-agent/releases/download/v<version>/gryphon-agent-namespaced.yaml
kubectl apply -n shop -f https://github.com/gocodedotca/gryphon-agent/releases/download/v<version>/gryphon-agent-role.yaml

Tout sauf la vérification des nœuds fonctionne dans les espaces de noms accordés. La vérification des nœuds a besoin d’un accès à toute la grappe, et le dit au lieu de signaler les nœuds comme en panne. Une vérification sur un espace de noms qui n’a pas été accordé à l’agent indique quel fichier y appliquer.

Plusieurs grappes

Chaque grappe est un hôte distinct, avec son propre jeton et son propre agent. Avec la préproduction et la production comme deux hôtes, leurs alertes restent séparées.

Derrière un proxy

Si la grappe accède à Internet par un proxy Web, donnez à l’agent l’adresse du proxy : kubectl -n gryphon set env deployment/gryphon-agent HTTPS_PROXY=http://proxy.internal:3128.