Distributions Kubernetes

Docs > Surveillance des conteneurs > Kubernetes > Distributions Kubernetes

Présentation

Cette section vise à documenter les spécificités et à fournir une bonne configuration de base pour toutes les principales distributions Kubernetes. Ces configurations peuvent ensuite être personnalisées pour ajouter n’importe quelle fonctionnalité 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.

Dans un cluster EKS, vous pouvez installer l’opérateur en utilisant Helm ou en tant qu’add-on EKS.

La configuration ci-dessous est conçue pour fonctionner avec les deux configurations (Helm ou add-on EKS) lorsque l’Agent est installé dans le même espace de nommage que l’opérateur Datadog.

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>

Azure Kubernetes Service (AKS)

Contrôleur d’admission

La fonctionnalité contrôleur d’admission facultative nécessite une configuration spécifique pour éviter une erreur lors de la réconciliation du webhook.

Ressource Kubernetes DatadogAgent :

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    site: <DATADOG_SITE>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  override:
    clusterAgent:
      containers:
        cluster-agent:
          env:
            - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS
              value: "true"

Remplacez <DATADOG_SITE> par votre site Datadog. Votre site est . (Assurez-vous que le SITE correct pour votre compte est sélectionné à droite de cette page).

datadog-values.yaml personnalisé :

datadog:
  clusterName: <CLUSTER_NAME>
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>

providers:
  aks:
    enabled: true

L’option providers.aks.enabled définit la variable d’environnement nécessaire DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS="true" pour vous.

Rotation des certificats de service Kubelet

Si votre cluster n’a pas la rotation des certificats de service Kubelet activée, vous devez fournir une configuration supplémentaire pour permettre à l’Agent Datadog de se connecter au Kubelet. La rotation des certificats de service Kubelet est activée dans les clusters Kubernetes 1.27 et versions ultérieures sur les pools de nœuds mis à jour après juillet 2025.

Vos nœuds disposent de cette fonctionnalité si ils possèdent l’étiquette kubernetes.azure.com/kubelet-serving-ca=cluster. Vérifiez si tous vos nœuds possèdent cette étiquette en exécutant :

kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca

Assurez-vous que tous vos nœuds affichent cluster.

Sans rotation des certificats de service Kubelet

Si la rotation des certificats de service Kubelet n’est pas activée, fournissez la configuration Kubelet supplémentaire suivante :

Ressource Kubernetes DatadogAgent :

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    site: <DATADOG_SITE>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
    kubelet:
      host:
        fieldRef:
          fieldPath: spec.nodeName
      hostCAPath: /etc/kubernetes/certs/kubeletserver.crt
  override:
    clusterAgent:
      containers:
        cluster-agent:
          env:
            - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS
              value: "true"

datadog-values.yaml personnalisé :

datadog:
  clusterName: <CLUSTER_NAME>
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>
  kubelet:
    host:
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    hostCAPath: /etc/kubernetes/certs/kubeletserver.crt

providers:
  aks:
    enabled: true

Dans ces versions de nœud AKS, le certificat Kubelet AKS nécessite de modifier le host Kubelet sur le spec.nodeName et l’emplacement hostCAPath du certificat, comme indiqué dans les extraits précédents. Cela active la vérification TLS. Sans ces modifications, l’Agent ne peut pas se connecter au Kubelet.

Une fois que la rotation des certificats de service Kubelet est activée dans votre cluster, supprimez cette configuration.

Lorsque vous mettez à niveau votre cluster AKS, vous pouvez voir la fonctionnalité de rotation des certificats de service Kubelet activée automatiquement pour vous, ce qui peut avoir un impact négatif sur votre Agent Datadog si vous utilisez la configuration spéciale ci-dessus pour référencer le certificat /etc/kubernetes/certs/kubeletserver.crt. Lorsque la rotation des certificats de service Kubelet est activée, ce certificat est supprimé, ce qui entraîne :

Dans l’opérateur Datadog : le conteneur de l’Agent s’arrête en Error, car il ne peut pas se connecter au Kubelet, et il enregistre Error while getting hostname, exiting: unable to reliably determine the host name
Dans Helm : le pod de l’Agent ne parvient pas à démarrer avec l’événement d’avertissement MountVolume.SetUp failed for volume "kubelet-ca" : hostPath type check failed: /etc/kubernetes/certs/kubeletserver.crt is not a file

Dans ces cas, supprimez les configurations Kubelet supplémentaires.

En alternative, vous pouvez également vous connecter au Kubelet sans vérification TLS.

Sans vérification TLS

Dans certains clusters, la résolution DNS pour spec.nodeName à l’intérieur des pods ne fonctionne pas dans AKS. Cela affecte :

Les nœuds Windows
Les nœuds Linux, lorsque le cluster est configuré dans un réseau virtuel utilisant un DNS personnalisé

Dans ce cas, utilisez la configuration AKS fournie ci-dessous pour définir tlsVerify: false et supprimer tous les paramètres pour le chemin host Kubelet (qui est défini par défaut sur status.hostIP). Ne définissez pas le chemin host Kubelet et tlsVerify: false dans la même configuration.

Ressource Kubernetes DatadogAgent :

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
    kubelet:
      tlsVerify: false
  override:
    clusterAgent:
      containers:
        cluster-agent:
          env:
            - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS
              value: "true"

datadog-values.yaml personnalisé :

datadog:
  clusterName: <CLUSTER_NAME>
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>
  kubelet:
    tlsVerify: false

providers:
  aks:
    enabled: 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 recommande de spécifier des limites de ressources pour le conteneur de l’Agent. Autopilot définit une limite par défaut relativement faible (50m CPU, 100Mi mémoire) qui peut amener le conteneur de l’Agent à rapidement atteindre OOMKill en fonction de votre environnement. Le cas échéant, spécifiez également les limites de ressources pour les conteneurs Trace Agent, Process Agent et System-Probe. De plus, vous pouvez souhaiter créer une classe de priorité pour l’Agent afin de garantir sa planification.

À partir de l’Agent 7.65.0+ et de la version 3.113.0+ du chart Helm, Datadog recommande d’utiliser datadog.kubelet.useApiServer pour que l’Agent interroge la liste des pods depuis l’API Server. Évitez d’utiliser le port Kubelet en lecture seule obsolète.

datadog-values.yaml personnalisé :

datadog:
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>
  clusterName: <CLUSTER_NAME>

  # The site of the Datadog intake to send Agent data to (example: `us3.datadoghq.com`)
  # Default value is `datadoghq.com' (the US1 site)
  # Documentation: https://docs.datadoghq.com/getting_started/site/
  site: <DATADOG_SITE>

  # This option uses the API server to retrieve the node-level pod list from the API server.
  # This setting is necessary to migrate away from the deprecated read-only kubelet port.
  # Requires Agent 7.65.0+ and Datadog Helm chart version 3.113.0+.
  kubelet:
    useApiServer: true

agents:
  containers:
    agent:
      # resources for the Agent container
      resources:
        requests:
          cpu: 200m
          memory: 256Mi

    traceAgent:
      # resources for the Trace Agent container
      resources:
        requests:
          cpu: 100m
          memory: 200Mi

    processAgent:
      # resources for the Process Agent container
      resources:
        requests:
          cpu: 100m
          memory: 200Mi

    systemProbe:
      # resources for the System Probe container
      resources:
        requests:
          cpu: 100m
          memory: 400Mi

  priorityClassCreate: true

providers:
  gke:
    autopilot: true

Pods Spot et classes de calcul

L’utilisation de pods Spot dans les clusters GKE Autopilot introduit des taints sur les nœuds GKE Spot correspondants. Lors de l’utilisation de pods Spot, une configuration supplémentaire est requise pour fournir au DaemonSet de l’Agent une tolérance correspondante.

agents:
  #(...)
  # agents.tolerations -- Allow the DaemonSet to schedule on tainted nodes (requires Kubernetes >= 1.6)
  tolerations:
  - effect: NoSchedule
    key: cloud.google.com/gke-spot
    operator: Equal
    value: "true"

De même, lors de l’utilisation de classes de calcul GKE Autopilot pour exécuter des workloads ayant des exigences matérielles spécifiques, prenez note des taints que GKE Autopilot applique à ces nœuds spécifiques et ajoutez des tolérances correspondantes au DaemonSet de l’Agent. Vous pouvez faire correspondre les tolérances sur vos pods correspondants. Par exemple, pour la classe de calcul Scale-Out, utilisez une tolérance comme :

agents:
  #(...)
  # agents.tolerations -- Allow the DaemonSet to schedule on tainted nodes (requires Kubernetes >= 1.6)
  tolerations:
  - effect: NoSchedule
    key: cloud.google.com/compute-class
    operator: Equal
    value: Scale-Out

Red Hat OpenShift

OpenShift est livré avec une sécurité renforcée par défaut avec SELinux et SecurityContextConstraints (SCC). Par conséquent, il nécessite certaines configurations spécifiques :

Accès SCC élevé pour l’Agent de nœud et l’Agent de cluster
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.
(Facultatif) Définir hostNetwork: true dans l’Agent de nœud pour permettre à l’Agent d’effectuer des requêtes vers les services de métadonnées du fournisseur de cloud (IMDS)

Cette configuration de base prend en charge OpenShift 3.11 et OpenShift 4, mais elle fonctionne mieux avec OpenShift 4.

De plus, la collecte de logs et APM ont également des exigences légèrement différentes.

L’utilisation de Socket de domaine Unix (UDS) pour APM et DogStatsD peut fonctionner dans OpenShift. Toutefois, Datadog ne recommande pas cela, car cela nécessite des autorisations privilégiées supplémentaires et un accès SCC pour à la fois votre pod de l’Agent Datadog et votre pod d’application. Sans celles-ci, votre pod d’application peut ne pas parvenir à se déployer. Datadog recommande de désactiver l’option UDS pour éviter cela, permettant au contrôleur d’admission d’injecter le paramètre TCP/IP ou le paramètre de service approprié pour la connectivité APM.

Lors de l’utilisation de l’opérateur Datadog dans OpenShift, Datadog recommande d’utiliser l’Operator Lifecycle Manager pour déployer l’opérateur Datadog depuis OperatorHub dans la console web de votre cluster OpenShift. Consultez les étapes d’installation de l’opérateur. La configuration ci-dessous fonctionne avec cette configuration, qui crée l’accès basé sur ClusterRole et ClusterRoleBinding au SCC pour le ServiceAccount spécifié datadog-agent-scc. Cette configuration DatadogAgent doit être déployée dans le même espace de nommage que l’opérateur Datadog.

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
  namespace: openshift-operators # set as the same namespace where the Datadog Operator was deployed
spec:
  features:
    logCollection:
      enabled: true
      containerCollectAll: true
    apm:
      enabled: true
      hostPortConfig:
        enabled: true
      unixDomainSocketConfig:
        enabled: false
    dogstatsd:
      unixDomainSocketConfig:
        enabled: false
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
    clusterName: <CLUSTER_NAME>
    kubelet:
      tlsVerify: false
  override:
    clusterAgent:
      serviceAccountName: datadog-agent-scc
    nodeAgent:
      serviceAccountName: datadog-agent-scc
      hostNetwork: true
      securityContext:
        runAsUser: 0
        seLinuxOptions:
          level: s0
          role: system_r
          type: spc_t
          user: system_u
      tolerations:
        - key: node-role.kubernetes.io/master
          operator: Exists
          effect: NoSchedule
        - key: node-role.kubernetes.io/infra
          operator: Exists
          effect: NoSchedule

Remarque : le remplacement nodeAgent.securityContext.seLinuxOptions est nécessaire pour la collecte de logs lors du déploiement avec l’opérateur. Si la collecte de logs n’est pas activée, vous pouvez omettre ce remplacement.

La configuration ci-dessous crée des SCC personnalisés pour les ServiceAccounts de l’Agent et de l’Agent de cluster.

datadog-values.yaml personnalisé :

datadog:
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>
  clusterName: <CLUSTER_NAME>
  kubelet:
    tlsVerify: false
  apm:
    portEnabled: true
    socketEnabled: false
agents:
  podSecurity:
    securityContextConstraints:
      create: true
  useHostNetwork: 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

Rancher

Les installations Rancher sont similaires aux installations Kubernetes standard, nécessitant seulement une configuration mineure :

Des tolérances sont requises pour planifier l’Agent de nœud sur les nœuds controlplane et etcd.
Le nom de cluster doit être défini car il ne peut pas être récupéré automatiquement depuis le fournisseur de cloud.

Ressource Kubernetes DatadogAgent :

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: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
    clusterName: <CLUSTER_NAME>
    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

datadog-values.yaml personnalisé :

datadog:
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>
  clusterName: <CLUSTER_NAME>
  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

Oracle Container Engine for Kubernetes (OKE)

Aucune configuration particulière n’est requise.

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.

Ressource Kubernetes DatadogAgent :

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    eventCollection:
      collectKubernetesEvents: true
    kubeStateMetricsCore:
      enabled: true
  global:
    clusterName: <CLUSTER_NAME>
    credentials:
      apiSecret:
        secretName: datadog-secret
        keyName: api-key
      appSecret:
        secretName: datadog-secret
        keyName: app-key
    kubelet:
      tlsVerify: false
  override:
    nodeAgent:
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule

datadog-values.yaml personnalisé :

datadog:
  clusterName: <CLUSTER_NAME>
  apiKey: <DATADOG_API_KEY>
  appKey: <DATADOG_APP_KEY>
  kubelet:
    # Set tlsVerify to false since the Kubelet certificates are self-signed
    tlsVerify: false
  # Disable the `kube-state-metrics` dependency chart installation.
  kubeStateMetricsEnabled: false
  # Enable the new `kubernetes_state_core` check.
  kubeStateMetricsCore:
    enabled: true
# Add a toleration so that the agent can be scheduled on the control plane nodes.
agents:
  tolerations:
    - key: node-role.kubernetes.io/master
      effect: NoSchedule