Cette section vise à documenter les spécificités et à fournir de bonnes configurations de base pour la surveillance du plan de contrôle Kubernetes. Vous pouvez ensuite personnaliser ces configurations pour ajouter toute fonctionnalité de Datadog.
Les configurations suivantes sont testées sur Kubernetes v1.18+.
Serveur API
L’intégration du serveur API est configurée automatiquement. L’Agent Datadog le découvre automatiquement.
Etcd
En fournissant un accès en lecture aux certificats Etcd situés sur l’hôte, l’Agent Datadog peut communiquer avec Etcd et commencer à collecter des métriques Etcd.
Si les ports non sécurisés de vos instances de Gestionnaire de contrôleur et de Planificateur sont activés, l’Agent Datadog découvre les intégrations et commence à collecter des métriques sans configuration supplémentaire.
Ports sécurisés
Les ports sécurisés permettent l’authentification et l’autorisation pour protéger vos composants de plan de contrôle. L’Agent Datadog peut collecter des métriques du Gestionnaire de contrôleur et du Planificateur en ciblant leurs ports sécurisés.
Le champ ssl_verify dans la configuration kube_controller_manager et kube_scheduler doit être défini sur false lors de l’utilisation de certificats auto-signés.
Lorsque vous ciblez des ports sécurisés, l’option bind-address dans votre configuration du Gestionnaire de Contrôleur et du Planificateur doit être accessible par l’Agent Datadog. Exemple :
Datadog prend en charge la surveillance des composants du Plan de Contrôle Kubernetes, y compris le Serveur API, le Gestionnaire de Contrôleur et le Planificateur.
Prérequis
Datadog Operator >= v1.18.0
Agent Datadog >= v7.69
Configuration générale
La surveillance du plan de contrôle est activée par défaut, mais nécessite que l’introspection soit activée.
Vous devriez voir les métriques du plan de contrôle dans Datadog, y compris :
kube_apiserver.*
kube_controller_manager.*
kube_scheduler.*
Configuration héritée
Amazon Elastic Kubernetes Service (EKS) prend en charge la surveillance de tous les composants du plan de contrôle à l’aide de vérifications de cluster.
Prérequis
Un cluster EKS fonctionnant sur la version Kubernetes >= 1.28
Déployez l’Agent en utilisant l’une des options suivantes :
Amazon expose les métriques kube_controller_manager et kube_scheduler sous le groupe d’API metrics.eks.amazonaws.com.
L’ajout de "extra_headers":{"accept":"*/*"} empêche les erreurs HTTP 406 lors de la requête de l’API des métriques EKS.
Kubernetes sur OpenShift 4
Cette fonctionnalité est en préversion.
Datadog prend en charge la surveillance des composants du plan de contrôle Kubernetes, y compris le serveur API, etcd, le gestionnaire de contrôleur et le planificateur.
Prérequis
Datadog Operator >= v1.18.0
Agent Datadog >= v7.69
Remarque : etcd n’est pas pris en charge sur les versions 4.0-4.13.
Configuration générale
La surveillance du plan de contrôle est activée par défaut, mais nécessite que l’introspection soit activée.
Ou, pour les utilisateurs d’OpenShift qui ont installé l’opérateur via OperatorHub/Marché (la méthode recommandée), en patchant la version du service de cluster de l’opérateur :
Puisque cette fonctionnalité est activée par défaut, vous pouvez déployer une spécification minimale de DatadogAgent.
Activez features.clusterChecks.useClusterChecksRunners pour planifier des vérifications là-bas ; sinon, les vérifications du plan de contrôle s’exécutent sur l’Agent Node.
Pour OpenShift 4.14 et versions ultérieures, la surveillance d’etcd nécessite de copier les certificats etcd. Vérifiez les journaux de l’opérateur pour la commande exacte. Voir l’exemple suivant (ajustez l’espace de noms si nécessaire) :
oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml |\
sed 's/namespace: openshift-etcd-operator/namespace: datadog/'|\
oc apply -f -
Prérequis
Version du chart Helm >= 3.150.0
Agent Datadog >= v7.69
Remarque : etcd n’est pas pris en charge sur les versions 4.0-4.13.
Configuration générale
Activez la surveillance du plan de contrôle en utilisant l’option providers.openshift.controlPlaneMonitoring :
Pour OpenShift 4.14 et versions ultérieures, la surveillance d’etcd nécessite de copier les certificats etcd. Pour les copier dans le même espace de noms que l’Agent Datadog :
oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/namespace: openshift-etcd-operator/namespace: <datadog agent namespace>/'| oc create -f -
Validation
Vérifiez que les vérifications sont en cours d’exécution :
Assurez-vous que vous êtes connecté avec des autorisations suffisantes pour modifier les services et créer des secrets.
Serveur API
Le serveur API fonctionne derrière le service kubernetes dans l’espace de noms default. Annotez ce service avec la configuration kube_apiserver_metrics :
oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.check_names=["kube_apiserver_metrics"]'oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "bearer_token_auth": "true"}]'oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.resolve=ip'
La dernière annotation ad.datadoghq.com/endpoints.resolve est nécessaire car le service est devant des pods statiques. L’Agent de Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les dispatches aux Exécuteurs de Vérification de Cluster. Les nœuds sur lesquels ils s’exécutent peuvent être identifiés avec :
Des certificats sont nécessaires pour communiquer avec le service Etcd, qui peut être trouvé dans le secret kube-etcd-client-certs dans l’espace de noms openshift-monitoring. Pour donner à l’Agent Datadog accès à ces certificats, copiez-les d’abord dans le même espace de noms que celui dans lequel l’Agent Datadog s’exécute :
oc get secret kube-etcd-client-certs -n openshift-monitoring -o yaml | sed 's/namespace: openshift-monitoring/namespace: <datadog agent namespace>/'| oc create -f -
Ces certificats doivent être montés sur les pods des Exécuteurs de Vérification de Cluster en ajoutant les volumes et les volumeMounts comme ci-dessous.
Note : Les montages sont également inclus pour désactiver le fichier de configuration automatique de vérification Etcd emballé avec l’agent.
Ensuite, annotez le service s’exécutant devant Etcd :
oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]'oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "tls_ca_cert": "/etc/etcd-certs/etcd-client-ca.crt", "tls_cert": "/etc/etcd-certs/etcd-client.crt",
"tls_private_key": "/etc/etcd-certs/etcd-client.key"}]'oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=ip'
L’Agent de Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les dispatches aux Exécuteurs de Vérification de Cluster.
Etcd OpenShift 4.14 et versions ultérieures
Des certificats sont nécessaires pour communiquer avec le service Etcd, qui peut être trouvé dans le secret etcd-metric-client dans l’espace de noms openshift-etcd-operator. Pour donner à l’Agent Datadog accès à ces certificats, copiez-les dans le même espace de noms que l’Agent Datadog :
oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/namespace: openshift-etcd-operator/namespace: <datadog agent namespace>/'| oc create -f -
Ces certificats doivent être montés sur les pods des Exécuteurs de Vérification de Cluster en ajoutant les volumes et les volumeMounts comme ci-dessous.
Note : Les montages sont également inclus pour désactiver le fichier de configuration automatique de vérification Etcd emballé avec l’agent.
Ensuite, annotez le service s’exécutant devant Etcd :
oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]'oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "tls_ca_cert": "/etc/etcd-certs/etcd-client-ca.crt", "tls_cert": "/etc/etcd-certs/etcd-client.crt",
"tls_private_key": "/etc/etcd-certs/etcd-client.key"}]'oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=ip'
L’Agent Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les transmet aux Cluster Check Runners.
Gestionnaire de Contrôleur
Le Gestionnaire de Contrôleur s’exécute derrière le service kube-controller-manager dans l’espace de noms openshift-kube-controller-manager. Annotez le service avec la configuration de vérification :
oc annotate service kube-controller-manager -n openshift-kube-controller-manager 'ad.datadoghq.com/endpoints.check_names=["kube_controller_manager"]'oc annotate service kube-controller-manager -n openshift-kube-controller-manager 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service kube-controller-manager -n openshift-kube-controller-manager 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "ssl_verify": "false", "bearer_token_auth": "true"}]'oc annotate service kube-controller-manager -n openshift-kube-controller-manager 'ad.datadoghq.com/endpoints.resolve=ip'
L’Agent Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les transmet aux Cluster Check Runners.
Planificateur
Le Planificateur s’exécute derrière le service scheduler dans l’espace de noms openshift-kube-scheduler. Annotez le service avec la configuration de vérification :
oc annotate service scheduler -n openshift-kube-scheduler 'ad.datadoghq.com/endpoints.check_names=["kube_scheduler"]'oc annotate service scheduler -n openshift-kube-scheduler 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service scheduler -n openshift-kube-scheduler 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "ssl_verify": "false", "bearer_token_auth": "true"}]'oc annotate service scheduler -n openshift-kube-scheduler 'ad.datadoghq.com/endpoints.resolve=ip'
L’Agent Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les transmet aux Cluster Check Runners.
Kubernetes sur OpenShift 3
Sur OpenShift 3, tous les composants du plan de contrôle peuvent être surveillés à l’aide de vérifications de point de terminaison.
Assurez-vous que vous êtes connecté avec des autorisations suffisantes pour créer et modifier des services.
Serveur API
Le serveur API fonctionne derrière le service kubernetes dans l’espace de noms default. Annotez ce service avec la configuration kube_apiserver_metrics :
oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.check_names=["kube_apiserver_metrics"]'oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "bearer_token_auth": "true"}]'oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.resolve=ip'
La dernière annotation ad.datadoghq.com/endpoints.resolve est nécessaire car le service est devant des pods statiques. L’Agent Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les transmet aux Cluster Check Runners. Les nœuds sur lesquels ils s’exécutent peuvent être identifiés avec :
Des certificats sont nécessaires pour communiquer avec le service Etcd, qui se trouve sur l’hôte. Ces certificats doivent être montés sur les pods des Cluster Check Runners en ajoutant les volumes et les volumeMounts comme ci-dessous.
Remarque : Les montages sont également inclus pour désactiver le fichier de configuration automatique de vérification Etcd fourni avec l’agent.
Les modifications directes de ce service ne sont pas conservées, donc faites une copie du service Etcd :
oc get service etcd -n kube-system -o yaml | sed 's/name: etcd/name: etcd-copy/'| oc create -f -
Annotez le service copié avec la configuration de vérification :
oc annotate service etcd-copy -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]'oc annotate service etcd-copy -n openshift-etcd 'ad.datadoghq.com/endpoints.init_configs=[{}]'oc annotate service etcd-copy -n openshift-etcd 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "tls_ca_cert": "/host/etc/etcd/ca/ca.crt", "tls_cert": "/host/etc/etcd/server.crt",
"tls_private_key": "/host/etc/etcd/server.key"}]'oc annotate service etcd-copy -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=ip'
L’Agent Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les transmet aux Cluster Check Runners.
Gestionnaire de contrôleur et planificateur
Le Gestionnaire de Contrôleur et le Planificateur s’exécutent derrière le même service, kube-controllers dans l’espace de noms kube-system. Les modifications directes du service ne sont pas conservées, donc faites une copie du service :
oc get service kube-controllers -n kube-system -o yaml | sed 's/name: kube-controllers/name: kube-controllers-copy/'| oc create -f -
Annotez le service copié avec les configurations de vérification :
L’Agent Cluster Datadog planifie les vérifications en tant que vérifications de point de terminaison et les transmet aux Cluster Check Runners.
Kubernetes sur Talos Linux
Helm est la méthode d’installation recommandée pour Talos Linux. Utilisez Helm en définissant le flag providers.talos.enabled sur true.
Serveur API
L’intégration du serveur API est configurée automatiquement. L’Agent Datadog le découvre automatiquement.
Etcd
En fournissant un accès en lecture aux certificats etcd situés sur l’hôte, la vérification de l’agent Datadog peut communiquer avec etcd et commencer à collecter des métriques etcd.
datadog-values.yaml
datadog:apiKey:<DATADOG_API_KEY>appKey:<DATADOG_APP_KEY>clusterName:<CLUSTER_NAME>kubelet:tlsVerify:falseignoreAutoConfig:- etcdconfd:etcd.yaml:|- # You can configure the Agent to only run this check on the host where etcd is running
# by using `ad_identifiers` for a pod that would only be running on a control-plane node.
# This is to avoid errors when the Agent is running on worker nodes.
# Another approach is to run a minimal pod on the control-plane node and use it for `ad_identifiers`.
ad_identifiers:
- kube-scheduler
instances:
# This is the node IP where metrics are exposed because kube-scheduler runs in host network mode.
# Otherwise, the IP could be hardcoded to the master node IP (also in the environment variable `DD_KUBERNETES_KUBELET_HOST`).
- prometheus_url: https://%%host%%:2379/metrics
tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt
tls_cert: /host/etc/kubernetes/pki/etcd/server.crt
tls_private_key: /host/etc/kubernetes/pki/etcd/server.keyagents:# Tolerations are needed to be scheduled on control-plane nodes running etcdtolerations:- key:node-role.kubernetes.io/control-planeoperator:Existseffect:NoSchedulevolumes:# On Talos, etcd certificates are stored in /system/secrets/etcd- hostPath:path:/system/secrets/etcdname:etcd-certsvolumeMounts:- name:etcd-certsmountPath:/host/etc/kubernetes/pki/etcdreadOnly:trueproviders:talos:enabled:true
Gestionnaire de Contrôleur et Planificateur
Ports sécurisés
Les ports sécurisés permettent l’authentification et l’autorisation pour protéger vos composants de plan de contrôle. L’Agent Datadog peut collecter des métriques du Gestionnaire de Contrôleur et du Planificateur en ciblant leurs ports sécurisés.
Le champ ssl_verify dans la configuration kube_controller_manager et kube_scheduler doit être défini sur false lors de l’utilisation de certificats auto-signés.
Lorsque vous ciblez des ports sécurisés, l’option bind-address dans votre configuration du Gestionnaire de Contrôleur et du Planificateur doit être accessible par l’Agent Datadog. Appliquez le patch ci-dessous aux nœuds de plan de contrôle lors de la génération du cluster ; ou, pour les nœuds Talos en cours d’exécution, exécutez talosctl patch mc -n <control-plane-node1,control-plane-node2> --patch @controlplane-datadog-monitoring-patch.yaml.
Rancher v2.5 s’appuie sur PushProx pour exposer les points de terminaison des métriques du plan de contrôle, ce qui permet à l’Agent Datadog d’exécuter des vérifications du plan de contrôle et de collecter des métriques.
Ajoutez des services Kubernetes pour configurer les vérifications d’Autodécouverte.
En ajoutant des services Kubernetes sans tête pour définir les configurations de vérification, l’Agent Datadog est capable de cibler les pods pushprox et de collecter des métriques.
Les composants du plan de contrôle s’exécutent sur Docker en dehors de Kubernetes. Dans Kubernetes, le service kubernetes dans l’espace de noms default cible l’IP(s) du nœud du plan de contrôle. Vous pouvez confirmer cela en exécutant $ kubectl describe endpoints kubernetes.
Annotez ce service avec des vérifications de point de terminaison (gérées par l’Agent Cluster Datadog) pour surveiller le Serveur API, le Gestionnaire de Contrôleur et le Planificateur :
Etcd s’exécute dans Docker en dehors de Kubernetes, et des certificats sont nécessaires pour communiquer avec le service Etcd. Les étapes suggérées pour configurer la surveillance d’Etcd nécessitent un accès SSH à un nœud du plan de contrôle exécutant Etcd.
Connectez-vous en SSH au nœud du plan de contrôle en suivant la documentation de Rancher. Confirmez qu’Etcd s’exécute dans un conteneur Docker avec $ docker ps, puis utilisez $ docker inspect etcd pour trouver l’emplacement des certificats utilisés dans la commande d’exécution ("Cmd"), ainsi que le chemin hôte des montages.
Les trois flags dans la commande à rechercher sont :
--trusted-ca-file
--cert-file
--key-file
En utilisant les informations de montage disponibles dans la sortie $ docker inspect etcd, définissez volumes et volumeMounts dans la configuration de l’Agent Datadog. Incluez également des tolérances afin que l’Agent Datadog puisse s’exécuter sur les nœuds du plan de contrôle.
Voici des exemples de configuration de l’Agent Datadog avec Helm et l’Opérateur Datadog :
Configurez un DaemonSet avec un conteneur de pause pour exécuter la vérification Etcd sur les nœuds exécutant Etcd. Ce DaemonSet s’exécute sur le réseau hôte afin qu’il puisse accéder au service Etcd. Il dispose également de la configuration de vérification et des tolérances nécessaires pour s’exécuter sur le(s) nœud(s) du plan de contrôle. Assurez-vous que les chemins des fichiers de certificat montés correspondent à ce que vous avez configuré sur votre instance, et remplacez la portion <...> en conséquence.
Pour déployer le DaemonSet et la configuration de vérification, exécutez
kubectl apply -f <filename>
Kubernetes sur des services gérés (AKS, GKE)
Sur d’autres services gérés, tels que le service Azure Kubernetes (AKS) et Google Kubernetes Engine (GKE), l’utilisateur ne peut pas accéder aux composants du plan de contrôle. En conséquence, il n’est pas possible d’exécuter les vérifications kube_apiserver, kube_controller_manager, kube_scheduler ou etcd dans ces environnements.
1
2
rulesets:- %!s(<nil>) # Rules to enforce .
Request a personalized demo
Commencer avec Datadog
Ask AI
AI-generated responses may be inaccurate. Verify important info.
