Installer l'Agent Datadog sur Kubernetes
Aperçu
Cette page fournit des instructions pour installer l’Agent Datadog dans un environnement Kubernetes.
Pour parcourir la documentation dédiée aux principales distributions Kubernetes, y compris AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift, Rancher et Oracle Container Engine pour Kubernetes (OKE) et découvrir des exemples, référez-vous à la section Distributions Kubernetes.
Pour parcourir la documentation dédiée à la surveillance du plan de contrôle Kubernetes ainsi que des exemples, consultez la section Surveillance du plan de contrôle Kubernetes.
Versions minimales de Kubernetes et de l’Agent Datadog
Pour utiliser certaines fonctionnalités des versions récentes de Kubernetes, vous devez exécuter des versions minimales de l’Agent Datadog et de l’Agent de cluster.
| Version de Kubernetes | Version de l’Agent | Version du Cluster Agent | Raison |
|---|
| 1.16.0+ | 7.19.0+ | 1.9.0+ | Dépréciation des métriques Kubelet |
| 1.21.0+ | 7.36.0+ | 1.20.0+ | Dépréciation des ressources Kubernetes |
| 1.22.0+ | 7.37.0+ | 7.37.0+ | Prend en charge le jeton de compte de service dynamique |
| 1.25.0+ | 7.40.0+ | 7.40.0+ | Prend en charge le groupe d’API v1 |
| 1.33.0+ | 7.67.0+ | 7.67.0+ | Corrige les incompatibilités avec Kubernetes AllocatedResources dans /pods la sortie |
Pour une compatibilité optimale, Datadog recommande de maintenir votre Cluster Agent et votre Agent sur des versions identiques.
Installation
Aidez-vous de la page Installation sur Kubernetes dans Datadog pour vous guider tout au long du processus d’installation.
Sélectionnez la méthode d’installation
Choisissez l’une des méthodes d’installation suivantes :
Si vous prévoyez de mettre en œuvre l'APM avec
Instrumentation par Étape Unique (SSI) dans votre environnement Kubernetes, installez l'Agent Datadog dans son propre espace de noms. SSI n'instrumente pas les pods dans le même espace de noms que l'Agent Datadog.
Installez l’Opérateur Datadog
Pour installer l’Operator Datadog dans votre espace de nommage actuel, exécutez :
helm repo add datadog https://helm.datadoghq.com
helm install datadog-operator datadog/datadog-operator
kubectl create secret generic datadog-secret --from-literal api-key=<DATADOG_API_KEY>
Configurez datadog-agent.yaml
Créez un fichier, datadog-agent.yaml, qui contient :
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
clusterName: <CLUSTER_NAME>
site: <DATADOG_SITE>
credentials:
apiSecret:
secretName: datadog-secret
keyName: api-key
- Remplacez
<CLUSTER_NAME> par un nom pour votre cluster. - Remplacez
<DATADOG_SITE> par votre site Datadog. Votre site est . (Assurez-vous que le bon SITE est sélectionné à droite).
Déployez l’Agent avec le fichier de configuration ci-dessus
Exécutez :
kubectl apply -f datadog-agent.yaml
Ajoutez le dépôt Helm de Datadog
Exécutez :
helm repo add datadog https://helm.datadoghq.com
helm repo update
kubectl create secret generic datadog-secret --from-literal api-key=<DATADOG_API_KEY>
Configurez datadog-values.yaml
Créez un fichier, datadog-values.yaml, qui contient:
datadog:
apiKeyExistingSecret: datadog-secret
clusterName: <CLUSTER_NAME>
site: <DATADOG_SITE>
- Remplacez
<CLUSTER_NAME> par un nom pour votre cluster. - Remplacez
<DATADOG_SITE> par votre site Datadog. Votre site est . (Assurez-vous que le bon SITE est sélectionné à droite).
Déployez l’Agent avec le fichier de configuration ci-dessus
Exécutez :
helm install datadog-agent -f datadog-values.yaml datadog/datadog
Pour Windows, ajoutez --set targetSystem=windows à la helm install commande.
Confirmez l’installation de l’Agent
Vérifiez que les pods de l’Agent (étiquetés avec app.kubernetes.io/component:agent) apparaissent sur la page Conteneurs dans Datadog. Les pods de l’Agent sont détectés dans les quelques minutes suivant le déploiement.
<CLUSTER_NAME> permet de définir la portée des hôtes et des Cluster Checks. Ce nom unique doit être composé d’éléments séparés par des points et respecter les restrictions suivantes:
- Ne doit contenir que des lettres minuscules, des chiffres et des tirets.
- Doit commencer par une lettre
- Doit se terminer par un chiffre ou une lettre
- Doit être inférieur ou égal à 80 caractères
Installation non privilégiée
Pour exécuter une installation non privilégiée, ajoutez ce qui suit securityContext à votre configuration par rapport à votre <USER_ID> et <GROUP ID> souhaités:
- Remplacez
<USER_ID> par l’UID pour exécuter l’Agent Datadog. Datadog recommande de définir cette valeur sur 100 pour l’utilisateur dd-agent préexistant pour l’Agent Datadog v7.48+. - Remplacez
<GROUP_ID> par l’ID de groupe qui possède le socket Docker ou containerd.
Cela définit le securityContext au niveau du pod pour l’Agent.
Pour exécuter une installation non privilégiée, ajoutez ce qui suit à datadog-agent.yaml:
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
clusterName: <CLUSTER_NAME>
site: <DATADOG_SITE>
credentials:
apiSecret:
secretName: datadog-secret
keyName: api-key
override:
nodeAgent:
securityContext:
runAsUser: <USER_ID>
supplementalGroups:
- <GROUP_ID>
Ensuite, déployez l’Agent:
kubectl apply -f datadog-agent.yaml
Pour exécuter une installation non privilégiée, ajoutez ce qui suit à votre fichier datadog-values.yaml:
datadog:
apiKeyExistingSecret: datadog-secret
clusterName: <CLUSTER_NAME>
site: <DATADOG_SITE>
securityContext:
runAsUser: <USER_ID>
supplementalGroups:
- <GROUP_ID>
Ensuite, déployez l’Agent:
helm install datadog-agent -f datadog-values.yaml datadog/datadog
Registres de conteneurs
Datadog publie des images de conteneurs dans le Registre de Conteneurs Datadog, Google Artifact Registry (GAR), Amazon ECR, Azure ACR et Docker Hub:
| Registry | Path |
|---|
| Datadog Container Registry | registry.datadoghq.com |
| Google Artifact Registry | gcr.io/datadoghq |
| Google Artifact Registry (Europe) | eu.gcr.io/datadoghq |
| Google Artifact Registry (Asia) | asia.gcr.io/datadoghq |
| Amazon ECR | public.ecr.aws/datadog |
| Azure ACR | datadoghq.azurecr.io |
| Docker Hub | docker.io/datadog |
Par défaut, le graphique Helm de l’Agent Datadog détermine le registre d’images de l’Agent à partir de votre site Datadog, du type de cluster et de registryMigrationMode. En fonction de ces valeurs et des exclusions d’environnement, les images de l’Agent peuvent être tirées du Registre de Conteneurs Datadog (registry.datadoghq.com) ou d’un registre spécifique au site. Le graphique Datadog Operator est inclus par défaut comme dépendance du graphique Helm de l’Agent Datadog. Depuis la version 2.19.0 du graphique Datadog Operator, lorsque vous installez l’Operator via cette dépendance, le registryMigrationMode du graphique Helm de l’Agent Datadog s’applique aux images de l’Agent gérées par l’Operator. Le chart Helm de l’Operator lui-même ne définit pas registryMigrationMode ; l’image du pod de l’Operator est contrôlée séparément par la valeur image.repository du chart de l’Operator.
Docker Hub est soumis à des limites de taux de tirage d'images. Si vous n'êtes pas client de Docker Hub, Datadog recommande de mettre à jour votre configuration de Datadog Agent et de Cluster Agent pour tirer d'un autre registre. Pour les instructions, voir
Changer votre registre de conteneurs.
Depuis la version 2.19.0 du graphique Datadog Operator, lorsque l’Operator est installé via la dépendance du graphique Helm de Datadog Agent, le graphique Helm de Datadog Agent registryMigrationMode peut utiliser registry.datadoghq.com pour les images d’Agent gérées par l’Operator. Les versions antérieures tiraient les images d’Agent de registres spécifiques au site (gcr.io/datadoghq, eu.gcr.io/datadoghq, asia.gcr.io/datadoghq ou datadoghq.azurecr.io). Pour continuer à utiliser les registres spécifiques au site précédents pour les images d’Agent dans ce chemin de déploiement, définissez registryMigrationMode: "" dans votre graphique Helm de Datadog Agent values.yaml. Ce paramètre n’a aucun effet lorsque vous définissez explicitement un registre, et ce n’est pas un paramètre dans le graphique Helm de l’Operator autonome. Pour utiliser un registre différent pour l’image du pod Operator, définissez image.repository dans votre Helm values.yaml de l’Operator.
Pour utiliser un registre de conteneurs différent, modifiez global.registry dans datadog-agent.yaml.
Par exemple, pour utiliser Amazon ECR :
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
clusterName: <CLUSTER_NAME>
registry: public.ecr.aws/datadog
site: <DATADOG_SITE>
credentials:
apiSecret:
secretName: datadog-secret
keyName: api-key
Pour utiliser un registre de conteneurs différent, modifiez registry dans datadog-values.yaml.
Par exemple, pour utiliser Amazon ECR :
registry: public.ecr.aws/datadog
datadog:
apiKeyExistingSecret: datadog-secret
site: <DATADOG_SITE>
Pour plus d’informations, voir Changer votre registre de conteneurs.
Désinstaller
kubectl delete datadogagent datadog
helm delete datadog-operator
Cette commande supprime toutes les ressources Kubernetes créées par l’installation de Datadog Operator et le déploiement de Datadog Agent.
helm uninstall datadog-agent
Étapes suivantes
Surveillez votre infrastructure dans Datadog
Utilisez la page Conteneurs pour avoir une visibilité sur votre infrastructure de conteneurs, avec des métriques de ressources et une recherche facettée. Pour des informations sur l’utilisation de la page Conteneurs, voir Vue des Conteneurs.
Utilisez la page Images de Conteneurs pour obtenir des informations sur chaque image utilisée dans votre environnement. Cette page affiche également les vulnérabilités trouvées dans vos images de conteneurs provenant de Sécurité Cloud. Pour des informations sur l’utilisation de la page Images de Conteneurs, voir la Vue des Images de Conteneurs.
La section Kubernetes présente un aperçu de toutes vos ressources Kubernetes. Orchestrator Explorer vous permet de surveiller l’état des pods, des déploiements et d’autres concepts Kubernetes dans un espace de noms ou une zone de disponibilité spécifique, de consulter les spécifications des ressources pour les pods échoués dans un déploiement, de corréler l’activité des nœuds avec les journaux associés, et plus encore. La page Resource Utilization fournit des informations sur la manière dont vos charges de travail Kubernetes utilisent vos ressources informatiques à travers votre infrastructure. Pour des informations sur l’utilisation de ces pages, consultez Orchestrator Explorer et Kubernetes Resource Utilization.
Activer les fonctionnalités
Documentation, liens et articles supplémentaires utiles:
Lectures complémentaires
Documentation, liens et articles supplémentaires utiles: