Testez l’autoscaling comme vous testez votre application. Testez-le en charge, cassez-le, voyez ce qui se passe après un incident. Sinon, vous trouverez les limites là où ça fait le plus mal.
L’observabilité n’a pas d’importance à moins qu’elle réponde aux questions
Kubernetes possède des montagnes de données. Des éléments tels que les journaux, les métriques, les traces, les événements, les audits, l’historique de déploiement, les redémarrages des conteneurs, le bruit du plan de contrôle, etc. Le véritable défi n’est pas de collecter des informations, mais plutôt de leur donner un sens. La CNCF et d’autres ont les meilleures pratiques en matière de journalisation et de télémétrie, comme centraliser les journaux et ne pas divulguer de secrets. C’est important, mais en fin de compte, les ingénieurs ont besoin de réponses, pas seulement de données. Quand quelque chose se brise, personne ne se demande : « Kubernetes est-il vivant ? » Ils veulent savoir ce qui a changé. Est-ce que quelque chose s’est produit ? Un pod est-il tombé en panne ? L’autoscaling s’est-il déclenché trop tard ? Un nœud était-il défectueux, un secret a-t-il été modifié, une politique réseau trop stricte, une base de données en aval étouffée ?
L’observabilité doit correspondre à de véritables questions opérationnelles et pas seulement à cocher des cases pour les journaux ou les métriques. Les tableaux de bord doivent correspondre à la propriété du service. Les alertes doivent avoir un sens pour les utilisateurs finaux. La télémétrie doit se connecter aux déploiements et aux incidents. Mesurez la rapidité avec laquelle les ingénieurs identifient la cause première, et pas seulement si vous disposez des données quelque part.
