Kubernetes

Remarque : les versions 6.0 et ultérieures de l’Agent prennent seulement en charge les versions de Kubernetes ultérieures à 1.7.6. Pour les versions antérieures de Kubernetes, consultez la section Versions antérieures de Kubernetes.

Il existe plusieurs manières de surveiller votre système Kubernetes avec Datadog. Choisissez en fonction de la structure de votre système et du type de surveillance souhaité. Quatre options sont disponibles à l’installation de l’Agent Datadog pour Kubernetes : DaemonSets, graphiques Helm, installer l’Agent directement sur le host, et l’Agent de cluster Datadog.

Installation

Il existe quatre options permettant de recueillir des métriques, des traces et des logs de vos clusters Kubernetes :

Installation de conteneur (conseillée) : l’Agent s’exécute dans un Pod. Cette implémentation est suffisante pour la majorité des cas d’utilisation, mais ne surveille pas la phase de démarrage de votre cluster Kubernetes.
Installation Helm : Helm est un gestionnaire de paquet pour Kubernetes qui vous permet d’installer facilement l’Agent Datadog et d’activer ses différentes fonctionnalités.
Installation host : si le kubelet rencontre un problème, et si l’Agent meurt en tant que conteneur, vous perdrez la visibilité sur le nœud. En revanche, si l’Agent s’exécute sur le nœud, vous pouvez surveiller le kubelet sur l’ensemble de son cycle de vie. Si cela est important pour vous, installez l’Agent comme un host.
Agent de cluster : pour les systèmes avec de très grands clusters Kubernetes, l’Agent de cluster Datadog peut réduire la charge serveur.

Remarque : un seul Agent Datadog doit fonctionner sur chaque nœud ; un sidecar par pod est généralement déconseillé et peut ne pas fonctionner comme prévu.

RBAC

Lorsque vous utilisez l’intégration Kubernetes et déployez les Agents dans un cluster Kubernetes, vous devez accorder un ensemble de droits pour optimiser l’intégration de l’Agent.

L’Agent doit pouvoir effectuer les actions suivantes :

get et update les Configmaps intitulées datadogtoken pour mettre à jour et récupérer la dernière version du token correspondant au dernier événement enregistré dans ETCD.
list et watch les Events pour extraire les événements du serveur d’API, les formater et les envoyer.
get, update, et create pour le Endpoint. Le Endpoint utilisé par l’Agent pour la fonction d’élection de Leader est nommé datadog-leader-election.
list la ressource componentstatuses afin d’envoyer des checks de service pour le statut des composants du plan de contrôle.

Des modèles sont disponibles dans manifests/rbac du référentiel GitHub de datadog-agent. Ils permettent de créer un compte de service dans l’espace de nommage par défaut, un rôle de cluster avec les droits ci-dessus et une liaison de rôle de cluster.