Faites passer votre monitoring Kubernetes au niveau supérieur

Si les environnements Kubernetes ne cessent de prendre de l'ampleur, ils deviennent également plus complexes et rendent ainsi plus difficile le monitoring de leurs performances et de leur intégrité. La mise à jour de notre intégration Kubernetes (v3) réduit de manière significative l'utilisation du CPU et de la mémoire, ajoute la prise en charge de plans de contrôle externes tels que Rancher, et apporte des améliorations aux messages de logs pour aider à l'identification des problèmes. Par exemple, dans les gros clusters, notre nouvelle intégration peut être configurée pour nécessiter 80 % moins de mémoire qu'avant. C'est une énorme amélioration.

Dans cet article, je vais couvrir les avantages de notre nouvelle intégration ainsi que quelques-unes des difficultés auxquelles nous avons dû faire face avec le passage à la version 3.

Pourquoi mettre l'intégration Kubernetes à niveau ?

Si vous utilisez une ancienne version de notre intégration Kubernetes (ou même si vous débutez avec le monitoring Kubernetes dans New Relic), la version 3 vous apporte de nombreux avantages.

• Réduction de l'utilisation de la mémoire : obtenez jusqu'à 80 % de réduction de l'utilisation de la mémoire dans les gros clusters grâce à l'amélioration d'un composant de scraping KSM (kube-state-metrics).
• Amélioration du dépannage : triez les bogues et résolvez les problèmes plus facilement grâce à l'amélioration des logs et du cycle de traitement.
• Configuration simplifiée : utilisez trois composants configurables individuellement, y compris les fichiers de configuration qui fournissent des paramètres plus granulaires pour chaque source de données.
• Scraping des plans de contrôle externes : réalisez le scraping des métriques à partir de composants hors de vos clusters.
• Intervalles de scraping plus flexibles : augmentez ou réduisez l'ingestion des données en fonction de vos besoins.

Comment mettre à niveau l'intégration Kubernetes

Si vous utilisez la version 2 et que vous êtes prêt à effectuer la mise à niveau, il vous suffit d'exécuter cette commande :

La mise à jour de votre configuration, de vos dashboards ou des alertes n'est pas nécessaire. Pour en savoir plus, consultez le guide de migration suivant. 

Amélioration en arrière‑plan de l'intégration Kubernetes

Lors de la mise à niveau de l'intégration, nous avons dû garder à l'esprit de nombreux facteurs. Nous voulions rendre la nouvelle intégration compatible avec la version 2, proposer d'importantes améliorations et faciliter le plus possible le passage à la version supérieure. Nous avions également besoin de tester sans cesse la nouvelle implémentation pendant que l'architecture d'intégration continuait d'évoluer.

Avec le passage à la version 3, nous avons décidé de profiter pleinement du modèle de déploiement Kubernetes et des capacités que nous n'avions pas encore utilisées. Pour l'expliquer, je vais être un peu technique.

Pour complètement déverrouiller les capacités Kubernetes, nous avons apporté ces améliorations :

• Déplacement des tâches de scraping vers des composants distincts : cela permet la prise de meilleures décisions d'intégration lors de la planification et du déploiement, non au moment de l'exécution.
• Passage à un schéma de sidecar : les processus d'intégration et d'agents ont été déplacés vers différents conteneurs ce qui permet de suivre les meilleures pratiques Kubernetes pour l'intégration.
• Ajout de la fonctionnalité permettant le scraping des plans de contrôle externes : cet ajout permet de prendre en charge des solutions comme Rancher et les apiServers gérés.
• Réduction de la complexité dans le système cache : grâce à l'utilisation des informateurs Kubernetes.
• Prise en charge supplémentaire des structures de données complexes dans des configurations d'intégration : les listes et plans, par exemple.
• Suppression de l'intervalle de scraping codé en dur pour les plans de contrôle : vous pouvez ainsi configurer manuellement l'intervalle pour qu'il réponde à vos besoins.

Les sections suivantes plongent dans les détails de chacune de ces améliorations.

Configuration de composants découplés

Pour éviter la duplication des données pendant le scraping KSM et les composants de plan de contrôle à partir d'un DaemonSet, nous avons réalisé une élection du responsable basée sur la localité.

Lors de la conception de la nouvelle architecture, nous avons dissocié les différentes tâches d'intégration en composants distincts devant être planifiés en workloads séparés. Chaque composant obtient ses propres configurations, ressources, annotations, logs, etc. En outre, le comportement des composants ne change plus en fonction des pods exécutés dans le même nœud. Comme décrit dans la section suivante, cela permet à l'intégration de prendre des décisions plus intelligentes lors de la planification et du déploiement, plutôt que lors de l'exécution.

La version 3 a un DaemonSet réalisant le scraping du processus Kubelet exécuté sur le nœud. Elle inclut également des déploiements distincts pour le scraping KSM (kube-state-metrics) et les composants du plan de contrôle /metrics. Notez qu'en fonction de votre configuration, le composant de plan de contrôle ainsi qu'un DaemonSet pourraient être déployés.

Enfin, l'optimisation de l'architecture d'intégration nous a permis de réduire la taille de la base de code ce qui améliore l'expérience d'intégration Kubernetes dans New Relic.

Utilisation d'un schéma de sidecar pour supprimer les processus inutiles

Dans la version 2, il y avait plusieurs processus par conteneur : l'agent d'infrastructure New Relic déclenchait l'exécution de l'intégration nri-kubernetes en tant que processus distinct. Cette approche signifiait que seuls les échecs dans le processus principal d'un conteneur remontaient à la surface et déclenchaient le redémarrage d'un pod.

Dans la version 2, l'intégration n'était pas le processus principal du conteneur, de sorte que si elle recevait une erreur de configuration ou d'erreur, l'échec n'était pas remonté à la surface. Il n'y avait pas de redémarrage automatique du pod, ce qui rendait difficile la détection des problèmes. 

La nouvelle implémentation dans la version 3 suit un schéma de sidecar avec un conteneur de scraping nri-kubernetes à côté d'un agent exécuté dans un autre sidecar. Le fait d'avoir un seul processus par conteneur donne à Kubernetes le contrôle sur le cycle de vie du processus d'intégration, ce qui permet de s'assurer que si une erreur entraîne l'échec de l'intégration, elle envoie une notification et le pod est redémarré.

Ajout d'une fonctionnalité de scraping des plans de contrôles externes

Avec la version 2, le scraping des plans de contrôle externes n'était pas possible, même si vous aviez indiqué une URL de scraping.

Avec l'intégration Kubernetes mise à jour dans la version 3, vous pouvez préciser un point de terminaison statique et si vous avez besoin d'éviter la duplication des données, vous pouvez déployer le composant de plan de contrôle en tant que déploiement et non en tant que DaemonSet.

Vous pouvez également préciser différentes méthodes d'authentification pour chaque composant, y compris les jetons du porteur et le protocole MTLS (Mutual Transport Layer Security).

Et grâce à Autodiscovery et d'autres configurations par défaut ajoutées, plusieurs options de prise en charge de Kubernetes sont incluses, dont Kubeadm, kind et minikube. Pour les options de configuration non proposées, vous pouvez configurer l'intégration pour qu'elle utilise tout sélecteur, URL ou méthode « auth ».

Configuration basée sur les variables de l'environnement

Dans la version 2, si vous vouliez configurer l'intégration, vous ne pouviez utiliser que les variables d'environnement. Cette approche rendait fastidieuse la prise en charge de scénarios complexes, car vous étiez limité aux configurations clé=valeur. Par exemple, le fait que l'option de configuration était une liste plate nous obligeait à ajouter des préfixes pour montrer à quel groupe les variables appartenaient. Cela créait une certaine confusion dès qu'il fallait ajouter un nouveau paramètre dans des groupes de configuration imbriqués, il nous fallait donc des variables d'environnement avec différents préfixes : DiscoveryCacheTTL, APIServerCacheTTL, APIServerCacheK8SVersionTTL, APIServerCacheK8SVersionTTLJitter.

La nouvelle intégration s'appuie sur une configuration YAML pour prendre en charge des structures de données plus complexes, telles que les listes et les plans, et elle permet aux clients de configurer davantage de paramètres d'intégration. Au premier abord, la nouvelle configuration YAML du graphique Helm semble plus complexe que la précédente. Toutefois, values.yaml fournit des expressions supplémentaires qui sont souvent utilisées dans les graphiques Helm.

Enfin, en ce qui concerne les changements de configuration, les instances sont automatiquement redémarrées pour recharger le fichier de configuration si Helm est utilisé en tant que méthode d'installation.

Suppression de la configuration de l'intervalle de scraping codée en dur

Dans la version 2, l'option de configuration de l'intervalle de scraping était codée en dur à 15 s, et vous souhaitiez peut-être pouvoir modifier cet intervalle.

C'est désormais possible ! Nous avons exposé ce paramètre afin de vous permettre de définir l'intervalle manuellement entre 10 et 40 secondes. L'intervalle par défaut est de 15 secondes. Le paramètre lowDataMode change automatiquement l'intervalle à 30 secondes et réduit la quantité de données extraites. 

Test en continu de la nouvelle architecture

Pour la version 3, nous avons ajouté un ensemble de tests d'intégration qui se sert de la détection améliorée et de l'approche modulaire pour envoyer des données statiques pré‑générées à chaque composant. 

Les tests de bout en bout ont été améliorés avec une nouvelle approche découplée de l'implémentation elle-même. Les tests installent un graphique dans un environnement Kubernetes et vérifient si toutes les entités créées et toutes les métriques contenues dans les fichiers de spécification Kubernetes sont rapportées. Ces tests ne dépendent pas d'une architecture spécifique et ils mettent tout le pipeline à l'épreuve, il est donc est possible de les exécuter quelle que soit la version ou l'implémentation de l'intégration. Nous avons pu les exécuter tout au long de la mise à niveau de la version 2 à la version 3, ce qui nous a permis de découvrir (et de résoudre) certains bogues existants.

Réduction des changements cassants

Pour vous faciliter le passage à la version 3, nous avons utilisé une couche de compatibilité dans le graphique Helm pour mapper les anciennes valeurs sur les nouvelles. De cette façon, vous bénéficiez de tous les avantages de la dernière version de nri-kubernetes sans les soucis des changements cassants ou de configuration.