TP : Superviser un cluster Kubernetes avec le Datadog Operator avec correction

Ce que vous allez apprendre dans ce TP

• Déployer l'Operator et l'agent
• Superviser une application par Autodiscovery
• Diagnostiquer avec agent status

Introduction #

Ce que vous allez apprendre dans cette section

• Déployer l'Operator et l'agent
• Superviser une application par Autodiscovery
• Diagnostiquer avec agent status

Contexte. L'équipe migre ses applications sur Kubernetes. Vous devez y retrouver la même visibilité que sur les VM, sans configuration manuelle par pod.

Prérequis : Compte Datadog (l'essai gratuit suffit) et sa clé d'API, Docker, kind, kubectl, helm  ·  Durée estimée : 45 min

Un cluster supervisé de façon déclarative.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Créer le cluster et installer l'Operator

   Pourquoi ? L'Operator gère l'agent à partir d'une seule ressource déclarative.

   Créez un cluster kind, installez l'Operator et le secret contenant la clé d'API.
   Voir la correction

   kind create cluster --name dd-lab
   helm repo add datadog https://helm.datadoghq.com && helm repo update
   helm install datadog-operator datadog/datadog-operator
   kubectl create secret generic datadog-secret --from-literal api-key="$DD_API_KEY"

2. 2. Déployer l'agent

   Pourquoi ? La ressource DatadogAgent décrit tout : site, clé, fonctionnalités.

   Écrivez et appliquez datadog-agent.yaml. Combien de pods agent obtenez-vous ?
   Voir la correction

   # datadog-agent.yaml
   apiVersion: datadoghq.com/v2alpha1
   kind: DatadogAgent
   metadata:
     name: datadog
   spec:
     global:
       clusterName: dd-lab
       site: datadoghq.eu            # adaptez à votre site
       credentials:
         apiSecret: { secretName: datadog-secret, keyName: api-key }
       kubelet: { tlsVerify: false } # nécessaire sur kind
     features:
       logCollection: { enabled: true, containerCollectAll: true }
       liveProcessCollection: { enabled: true }

   kubectl apply -f datadog-agent.yaml
   kubectl get pods -w

   Un pod datadog-agent par nœud (un seul sur kind) et un pod datadog-cluster-agent.

3. 3. Déployer une application

   Pourquoi ? Les annotations Autodiscovery configurent le check dès le démarrage du pod.

   Déployez Redis avec les annotations du check redisdb et les labels de tagging unifié.
   Voir la correction

   # redis.yaml
   apiVersion: apps/v1
   kind: Deployment
   metadata: { name: cache }
   spec:
     selector: { matchLabels: { app: cache } }
     template:
       metadata:
         labels:
           app: cache
           tags.datadoghq.com/env: lab
           tags.datadoghq.com/service: cache
           tags.datadoghq.com/version: "7"
         annotations:
           ad.datadoghq.com/redis.checks: '{"redisdb": {"instances": [{"host": "%%host%%", "port": "6379"}]}}'
           ad.datadoghq.com/redis.logs: '[{"source": "redis", "service": "cache"}]'
       spec:
         containers:
           - { name: redis, image: "redis:7" }

   kubectl apply -f redis.yaml

4. 4. Vérifier côté agent

   Pourquoi ? agent status et configcheck disent si la configuration a été trouvée et si le check tourne.

   Vérifiez que le check Redis est découvert et exécuté.
   Voir la correction

   kubectl exec -it ds/datadog-agent -c agent -- agent status | sed -n '/redisdb/,/^$/p'
   kubectl exec -it ds/datadog-agent -c agent -- agent configcheck | grep -A5 redisdb

   Le check redisdb apparaît avec [OK] ; configcheck montre l'hôte résolu du pod.

5. 5. Vérifier dans Datadog

   Pourquoi ? Le tagging unifié relie métriques, logs et conteneur.

   Dans Datadog, filtrez par service:cache : retrouvez les métriques redis.*, les logs du conteneur et le pod dans l'explorateur Kubernetes.
   Voir la correction

   Les métriques redis.net.clients et les logs portent env:lab, service:cache, version:7. Nettoyez ensuite : kind delete cluster --name dd-lab.

Niveau de difficulté : ●●●○○ (3/5)