Distributions Kubernetes

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)

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) :

values.yaml personnalisé :

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

Ressource Kubernetes DatadogAgent :

apiVersion: datadoghq.com/v1alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  credentials:
    apiKey: <CLÉ_API_DATADOG>
    appKey: <CLÉ_APPLICATION_DATADOG>
  agent:
    config:
      criSocket:
        criSocketPath: /run/dockershim.sock
  clusterAgent:
    image:
      name: "gcr.io/datadoghq/cluster-agent:latest"
    config:
      externalMetrics:
        enabled: false
      admissionController:
        enabled: false

Azure Kubernetes Service (AKS)

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

values.yaml personnalisé :

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>
  kubelet:
    host:
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    hostCAPath: /etc/kubernetes/certs/kubeletserver.crt
    tlsVerify: false # Requis depuis la version 7.35 de l'Agent. Voir les remarques.

Ressource Kubernetes DatadogAgent :

apiVersion: datadoghq.com/v1alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  credentials:
    apiKey: <CLÉ_API_DATADOG>
    appKey: <CLÉ_APPLICATION_DATADOG>
  agent:
    config:
      kubelet:
        host:
          fieldRef:
            fieldPath: spec.nodeName
        hostCAPath: /etc/kubernetes/certs/kubeletserver.crt
        tlsVerify: false # Requis depuis la version 7.35 de l'Agent. Voir les remarques.
  clusterAgent:
    image:
      name: "gcr.io/datadoghq/cluster-agent:latest"
    config:
      externalMetrics:
        enabled: false
      admissionController:
        enabled: false

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"
    

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 ne sont pas disponibles, car des en-têtes de kernel ne sont pas fournis.

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.

values.yaml personnalisé :

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

  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.

values.yaml personnalisé :

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

Si vous utilisez l’Operator Datadog dans OpenShift, il est conseillé de l’installer par l’intermédiaire d’OperatorHub ou du Marketplace Redhat. La configuration ci-dessous a été conçue pour un environnement où l’Agent est installé dans le même espace de nommage que l’Operator Datadog (en raison des paramètres SCC/ServiceAccount).

apiVersion: datadoghq.com/v1alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  credentials:
    apiKey: <CLÉ_API_DATADOG>
    appKey: <CLÉ_APPLICATION_DATADOG>
  clusterName: <NOM_CLUSTER>
  agent:
    image:
      name: "gcr.io/datadoghq/agent:latest"
    apm:
      enabled: false
    process:
      enabled: true
      processCollectionEnabled: false
    log:
      enabled: false
    systemProbe:
      enabled: false
    security:
      compliance:
        enabled: false
      runtime:
        enabled: false
    rbac:
      serviceAccountName: datadog-agent-scc
    config:
      kubelet:
        tlsVerify: false
      criSocket:
        criSocketPath: /var/run/crio/crio.sock
        useCriSocketVolume: true
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        operator: Exists
  clusterAgent:
    image:
      name: "gcr.io/datadoghq/cluster-agent:latest"
    config:
      externalMetrics:
        enabled: false
        port: 8443
      admissionController:
        enabled: false

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.

values.yaml personnalisé :

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

Ressource Kubernetes DatadogAgent :

apiVersion: datadoghq.com/v1alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  credentials:
    apiKey: <CLÉ_API_DATADOG>
    appKey: <CLÉ_APPLICATION_DATADOG>
  clusterName: <NOM_CLUSTER>
  agent:
    image:
      name: "gcr.io/datadoghq/agent:latest"
    apm:
      enabled: false
    process:
      enabled: true
      processCollectionEnabled: false
    log:
      enabled: false
    systemProbe:
      enabled: false
    security:
      compliance:
        enabled: false
      runtime:
        enabled: false
    config:
      kubelet:
        tlsVerify: false
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/controlplane
        operator: Exists
      - effect: NoExecute
        key: node-role.kubernetes.io/etcd
        operator: Exists
  clusterAgent:
    image:
      name: "gcr.io/datadoghq/cluster-agent:latest"
    config:
      externalMetrics:
        enabled: false
      admissionController:
        enabled: false

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) :

values.yaml personnalisé :

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

Ressource Kubernetes DatadogAgent :

apiVersion: datadoghq.com/v1alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  credentials:
    apiKey: <CLÉ_API_DATADOG>
    appKey: <CLÉ_APPLICATION_DATADOG>
  agent:
    config:
      criSocket:
        criSocketPath: /run/dockershim.sock
  clusterAgent:
    image:
      name: "gcr.io/datadoghq/cluster-agent:latest"
    config:
      externalMetrics:
        enabled: false
      admissionController:
        enabled: false

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.