Présentation

Cette section présente les particularités des principales distributions Kubernetes et propose des modèles de configuration dont vous pouvez vous servir comme de point de départ. Chacune de ces configurations peut être personnalisée afin d’intégrer des fonctionnalités Datadog.

• AWS Elastic Kubernetes Service (EKS)
• Azure Kubernetes Service (AKS)
• Google Kubernetes Engine (GKE)
• Red Hat OpenShift
• Rancher
• Oracle Container Engine for Kubernetes (OKE)
• vSphere Tanzu Kubernetes Grid (TKG)

AWS Elastic Kubernetes Service (EKS)

Aucune configuration particulière n’est requise.

Si vous utilisez le système d’exploitation AWS Bottlerocket sur vos nœuds, ajoutez ce qui suit pour activer la surveillance des conteneurs (check containerd) :

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  criSocketPath: /run/dockershim.sock
  env:
  - name: DD_AUTOCONFIG_INCLUDE_FEATURES
    value: "containerd"

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    admissionController:
      enabled: false
    externalMetricsServer:
      enabled: false
      useDatadogMetrics: false
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
    criSocketPath: /run/dockershim.sock
  override:
    clusterAgent:
      image:
        name: gcr.io/datadoghq/cluster-agent:latest

Azure Kubernetes Service (AKS)

L’intégration Kubelet nécessite une configuration spécifique afin de prendre en charge les certificats AKS.

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  kubelet:
    tlsVerify: false # Obligatoire à partir de l'Agent 7.35. Voir la section Remarques.

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    admissionController:
      enabled: true
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
    kubelet:
      tlsVerify: false # Obligatoire à partir de l'Agent 7.35. Voir la section Remarques.
  override:
    clusterAgent:
      containers:
        cluster-agent:
          env:
            - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS
              value: "true"

Remarques :

• Depuis la version 7.35 de l’Agent, tlsVerify: false est requis, car aucun autre nom de l’objet (Subject Alternative Name ou SAN) n’est défini pour les certificats Kubelet dans AKS.

• Avec certaines configurations, il est possible que la résolution DNS pour spec.nodeName dans les nœuds ne fonctionne pas dans AKS. Ce problème a été signalé sur tous les nœuds AKS Windows, et lorsque le cluster est configuré dans un réseau virtuel avec un DNS personnalisé sur des nœuds Linux. Dans ce cas, vous devez impérativement supprimer le champ agent.config.kubelet.host (valeur par défaut : status.hostIP) et utiliser tlsVerify: false. La variable d’environnement DD_KUBELET_TLS_VERIFY=false résout également ce problème. Ces deux méthodes permettent de désactiver la vérification du certificat du serveur.

  env:
    - name: DD_KUBELET_TLS_VERIFY
      value: "false"
  

  Copy

• La fonctionnalité Contrôleur d’admission sur AKS nécessite d’ajouter des sélecteurs pour éviter une erreur lors du rapprochement du webhook :

clusterAgent:
  env:
    - name: "DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS"
      value: "true"

Google Kubernetes Engine (GKE)

Il est possible de configurer deux modes d’opération pour GKE :

• Standard : vous gérez l’infrastructure sous-jacente du cluster, ce qui vous fournit une plus grande flexibilité pour la configuration des nœuds.
• Autopilot : GKE provisionne et gère toute l’infrastructure sous-jacente du cluster, y compris les nœuds et les pools de nœuds. Vous disposez ainsi d’un cluster optimisé pour un fonctionnement autonome.

Vous devez adapter la configuration de l’Agent Datadog en fonction du mode d’opération de votre cluster.

Standard

Depuis la version 7.26 de l’Agent, aucune spécification spécifique n’est requise pour le mode Standard de GKE (que vous utilisiez Docker ou containerd).

Remarque : si vous utilisez COS (Container Optimized OS), les checks OOM Kill et TCP Queue Length basés sur eBPF sont pris en charge à partir de la version 3.0.1 du chart Helm. Pour activer ces checks, configurez le paramètre suivant :

• datadog.systemProbe.enableDefaultKernelHeadersPaths sur false.

Autopilot

Le mode Autopilot de GKE requiert une configuration précise, indiquée ci-dessous.

Datadog vous conseille de spécifier des limites de ressources pour le conteneur de l’Agent. La limite par défaut d’Autopilot est relativement basse (50 mCPU et 100 Mi pour la mémoire) et peut rapidement entraîner l’OOMKill du conteneur de l’Agent, en fonction de votre environnement. Le cas échéant, définissez d’autres limites de ressources pour les conteneurs de l’Agent de trace et de l’Agent de processus.

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  clusterName: <NOM_CLUSTER>

  # Activer le nouveau check `kubernetes_state_core`.
  kubeStateMetricsCore:
    enabled: true
  # Éviter de déployer le chart kube-state-metrics.
  # Le nouveau `kubernetes_state_core` ne nécessite plus le déploiement de kube-state-metrics.
  kubeStateMetricsEnabled: false

agents:
  containers:
    agent:
      # Ressources pour le conteneur de l'Agent
      resources:
        requests:
          cpu: 200m
          memory: 256Mi
        limits:
          cpu: 200m
          memory: 256Mi

    traceAgent:
      # Ressources pour le conteneur de l'Agent de trace
      resources:
        requests:
          cpu: 100m
          memory: 200Mi
        limits:
          cpu: 100m
          memory: 200Mi

    processAgent:
      # Ressources pour le conteneur de l'Agent de processus
      resources:
        requests:
          cpu: 100m
          memory: 200Mi
        limits:
          cpu: 100m
          memory: 200Mi

providers:
  gke:
    autopilot: true

Red Hat OpenShift

OpenShift est doté par défaut d’une sécurité renforcée (SELinux et SecurityContextConstraints) et nécessite donc une configuration particulière :

• Créez une SCC pour l’Agent de nœud et l’Agent de cluster.
• Indiquez le chemin du socket CRI, car OpenShift utilise le runtime de conteneur CRI-O.
• Il arrive que les certificats d’API Kubelet ne soient pas signés par l’autorité de certification du cluster.
• Vous devez définir des tolérances pour planifier l’Agent de nœud sur les nœuds master et infra.
• Le nom du cluster doit être défini et ne peut pas être récupéré automatiquement à partir du fournisseur de cloud.

Cette configuration est disponible pour OpenShift 3.11 et 4, mais est optimisée pour OpenShift 4.

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  clusterName: <NOM_CLUSTER>
  criSocketPath: /var/run/crio/crio.sock
  # Selon votre configuration DNS/SSL, il n'est pas forcément possible de vérifier correctement le certificat.
  # Si vous utilisez une autorité de certification adéquate, vous pouvez définir ce paramètre sur true.
  kubelet:
    tlsVerify: false
agents:
  podSecurity:
    securityContextConstraints:
      create: true
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
    operator: Exists
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    operator: Exists
clusterAgent:
  podSecurity:
    securityContextConstraints:
      create: true
kube-state-metrics:
  securityContext:
    enabled: false

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    logCollection:
      enabled: false
    liveProcessCollection:
      enabled: false
    liveContainerCollection:
      enabled: true
    apm:
      enabled: false
    cspm:
      enabled: false
    cws:
      enabled: false
    npm:
      enabled: false
    admissionController:
      enabled: false
    externalMetricsServer:
      enabled: false
      useDatadogMetrics: false
      port: 8443
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
    clusterName: <NOM_CLUSTER>
    kubelet:
      tlsVerify: false
    criSocketPath: /var/run/crio/crio.sock
  override:
    clusterAgent:
      image:
        name: gcr.io/datadoghq/cluster-agent:latest
    nodeAgent:
      serviceAccountName: datadog-agent-scc
      image:
        name: gcr.io/datadoghq/agent:latest
      tolerations:
        - key: node-role.kubernetes.io/master
          operator: Exists
          effect: NoSchedule
        - key: node-role.kubernetes.io/infra
          operator: Exists
          effect: NoSchedule

Rancher

Les installations Rancher sont semblables aux installations Kubernetes de base. Leur configuration requiert uniquement quelques ajustements :

• Vous devez définir des tolérances pour planifier l’Agent de nœud sur les nœuds controlplane et etcd.
• Le nom du cluster doit être défini et ne peut pas être récupéré automatiquement à partir du fournisseur de cloud.

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  clusterName: <NOM_CLUSTER>
  kubelet:
    tlsVerify: false
agents:
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/controlplane
    operator: Exists
  - effect: NoExecute
    key: node-role.kubernetes.io/etcd
    operator: Exists

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    logCollection:
      enabled: false
    liveProcessCollection:
      enabled: false
    liveContainerCollection:
      enabled: true
    apm:
      enabled: false
    cspm:
      enabled: false
    cws:
      enabled: false
    npm:
      enabled: false
    admissionController:
      enabled: false
    externalMetricsServer:
      enabled: false
      useDatadogMetrics: false
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
    clusterName: <NOM_CLUSTER>
    kubelet:
      tlsVerify: false
  override:
    clusterAgent:
      image:
        name: gcr.io/datadoghq/cluster-agent:latest
    nodeAgent:
      image:
        name: gcr.io/datadoghq/agent:latest
      tolerations:
        - key: node-role.kubernetes.io/controlplane
          operator: Exists
          effect: NoSchedule
        - key: node-role.kubernetes.io/etcd
          operator: Exists
          effect: NoExecute

Oracle Container Engine for Kubernetes (OKE)

Aucune configuration particulière n’est requise.

Pour activer la surveillance des conteneurs, ajoutez ce qui suit (check containerd) :

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  criSocketPath: /run/dockershim.sock
  env:
  - name: DD_AUTOCONFIG_INCLUDE_FEATURES
    value: "containerd"

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    admissionController:
      enabled: false
    externalMetricsServer:
      enabled: false
      useDatadogMetrics: false
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
    criSocketPath: /run/dockershim.sock
  override:
    clusterAgent:
      image:
        name: gcr.io/datadoghq/cluster-agent:latest

Le référentiel helm-charts contient d’autres exemples de fichier values.yaml. Le référentiel datadog-operator contient d’autres exemples de DatadogAgent.

vSphere Tanzu Kubernetes Grid (TKG)

TKG nécessite quelques légères modifications de la configuration, visibles ci-dessous. Par exemple, il est nécessaire de configurer une tolérance pour que le contrôleur planifie l’Agent de nœud sur les nœuds master.

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  kubelet:
    # Définir tlsVerify sur false étant donné que les certificats Kubelet sont autosignés
    tlsVerify: false
  # Désactiver l'installation du chart de la dépendance `kube-state-metrics`.
  kubeStateMetricsEnabled: false
  # Activer le nouveau check `kubernetes_state_core`.
  kubeStateMetricsCore:
    enabled: true
# Ajouter une tolérance pour que l'Agent puisse être planifié sur les nœuds du plan de contrôle.
agents:
  tolerations:
    - key: node-role.kubernetes.io/master
      effect: NoSchedule

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    eventCollection:
      collectKubernetesEvents: true
    kubeStateMetricsCore:
      # Activer le nouveau check `kubernetes_state_core`.
      enabled: true
  global:
    credentials:
      apiSecret:
        secretName: datadog-secret
        keyName: api-key
      appSecret:
        secretName: datadog-secret
        keyName: app-key
    kubelet:
      # Définir tlsVerify sur false étant donné que les certificats Kubelet sont autosignés
      tlsVerify: false
  override:
    nodeAgent:
      # Ajouter une tolérance pour que l'Agent puisse être planifié sur les nœuds du plan de contrôle.
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule

Documentation, liens et articles supplémentaires utiles:

Recueillir les logs de votre applicationDOCUMENTATION Recueillir les traces de vos applicationsDOCUMENTATION Recueillir vos métriques PrometheusDOCUMENTATION Recueillir automatiquement les métriques et les logs de vos applicationsDOCUMENTATION Limiter la collecte de données à un sous-ensemble de conteneursDOCUMENTATION Attribuer des tags à toutes les données envoyées par un conteneurDOCUMENTATION Suivre Tanzu Kubernetes Grid sur vSphereBLOG