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.
Documentation, liens et articles supplémentaires utiles:
