Esta sección tiene como objetivo documentar especificidades y proporcionar buenas configuraciones base para monitorear el Plano de Control de Kubernetes. Luego puedes personalizar estas configuraciones para agregar cualquier característica de Datadog.
Las siguientes configuraciones se prueban en Kubernetes v1.18+.
Servidor API
La integración del servidor API se configura automáticamente. El Agente de Datadog lo descubre automáticamente.
Etcd
Al proporcionar acceso de lectura a los certificados de Etcd ubicados en el servidor, la verificación del Agente de Datadog puede comunicarse con Etcd y comenzar a recopilar métricas de Etcd.
Si los puertos inseguros de sus instancias de Administrador de Controladores y Programador están habilitados, el Agente de Datadog descubre las integraciones y comienza a recopilar métricas sin ninguna configuración adicional.
Puertos seguros
Los puertos seguros permiten la autenticación y autorización para proteger los componentes de su Plano de Control. El Agente de Datadog puede recopilar métricas del Administrador de Controladores y del Programador dirigiéndose a sus puertos seguros.
El campo ssl_verify en la configuración de kube_controller_manager y kube_scheduler necesita ser establecido en false al usar certificados autofirmados.
Al apuntar a puertos seguros, la opción bind-address en la configuración de su Administrador de Controladores y Programador debe ser accesible por el Agente de Datadog. Ejemplo:
Datadog admite el monitoreo de los componentes del plano de control de Kubernetes, incluidos el servidor API, el Administrador de Controladores y el Programador.
Requisitos previos
Datadog Operator >= v1.18.0
Agente de Datadog >= v7.69
Configuración general
El monitoreo del plano de control está habilitado por defecto, pero requiere que la introspección esté habilitada.
Amazon expone métricas kube_controller_manager y kube_scheduler bajo el grupo de API metrics.eks.amazonaws.com.
La adición de "extra_headers":{"accept":"*/*"} previene errores HTTP 406 al consultar la API de métricas de EKS.
Kubernetes en OpenShift 4
Esta función está en vista previa.
Datadog admite el monitoreo de los componentes del plano de control de Kubernetes, incluidos el servidor API, Etcd, el Administrador de Controladores y el Programador.
Requisitos previos
Datadog Operator >= v1.18.0
Agente de Datadog >= v7.69
Nota: etcd no es compatible con las versiones 4.0-4.13.
Configuración general
El monitoreo del plano de control está habilitado por defecto, pero requiere que la introspección esté habilitada.
O, para usuarios de OpenShift que instalaron el Datadog Operator a través de OperatorHub/Marketplace (el método recomendado), parcheando la versión del servicio del clúster del operador:
Dado que esta función está habilitada por defecto, puedes implementar una especificación mínima de DatadogAgent.
Habilite features.clusterChecks.useClusterChecksRunners para programar verificaciones allí; de lo contrario, las verificaciones del plano de control se ejecutan en el Agente de Nodo.
Para OpenShift 4.14 y versiones posteriores, la supervisión de etcd requiere que copie los certificados de etcd. Revisa los registros del operador para obtener el comando exacto. Revisa el siguiente ejemplo (ajusta el espacio de nombres según sea necesario):
oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml |\
sed 's/namespace: openshift-etcd-operator/namespace: datadog/'|\
oc apply -f -
Requisitos previos
Versión del chart de Helm >= 3.150.0
Agente de Datadog >= v7.69
Nota: etcd no es compatible con las versiones 4.0-4.13.
Configuración general
Habilita el monitoreo del plano de control utilizando la opción providers.openshift.controlPlaneMonitoring:
Para OpenShift 4.14 y versiones posteriores, el monitoreo de Etcd requiere que copies los certificados de Etcd. Para copiarlos en el mismo espacio de nombres que el Agente de 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 -
Validación
Verifica que las verificaciones estén en ejecución:
Asegúrate de haber iniciado sesión con permisos suficientes para editar servicios y crear secretos.
Servidor API
El servidor API se ejecuta detrás del servicio kubernetes en el espacio de nombres default. Anota este servicio con la configuración 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 última anotación ad.datadoghq.com/endpoints.resolve es necesaria porque el servicio está frente a los pods estáticos. El Datadog Cluster Agent programa las verificaciones como verificaciones de punto final y las despacha a los Cluster Check Runners. Los nodos en los que se están ejecutando pueden ser identificados con:
Se necesitan certificados para comunicarse con el servicio Etcd, que se pueden encontrar en el secreto kube-etcd-client-certs en el espacio de nombres openshift-monitoring. Para dar acceso al Datadog Agent a estos certificados, primero cópielos en el mismo espacio de nombres en el que se está ejecutando el Datadog Agent:
oc get secret kube-etcd-client-certs -n openshift-monitoring -o yaml | sed 's/namespace: openshift-monitoring/namespace: <datadog agent namespace>/'| oc create -f -
Estos certificados deben montarse en los pods Cluster Check Runner agregando los volumes y volumeMounts como se indica a continuación.
Nota: También se incluyen montajes para deshabilitar el archivo de autoconfiguración de verificación de Etcd empaquetado con el agente.
Luego, anote el servicio que se está ejecutando frente a 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'
El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners.
Etcd OpenShift 4.14 y versiones posteriores
Se necesitan certificados para comunicarse con el servicio Etcd, que se pueden encontrar en el secreto etcd-metric-client en el espacio de nombres openshift-etcd-operator. Para dar acceso al Datadog Agent a estos certificados, cópielos en el mismo espacio de nombres que el Datadog Agent:
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 -
Estos certificados deben montarse en los pods Cluster Check Runner agregando los volumes y volumeMounts como se indica a continuación.
Nota: También se incluyen montajes para deshabilitar el archivo de autoconfiguración de verificación de Etcd empaquetado con el agente.
Luego, anote el servicio que se está ejecutando frente a 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'
El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners.
Controller Manager
El Controller Manager se ejecuta detrás del servicio kube-controller-manager en el espacio de nombres openshift-kube-controller-manager. Anote el servicio con la configuración de verificación:
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'
El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners.
Scheduler
El Scheduler se ejecuta detrás del servicio scheduler en el espacio de nombres openshift-kube-scheduler. Anote el servicio con la configuración de verificación:
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'
El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners.
Kubernetes en OpenShift 3
En OpenShift 3, todos los componentes del plano de control pueden ser monitoreados utilizando verificaciones de punto de conexión.
Asegúrese de haber iniciado sesión con permisos suficientes para crear y editar servicios.
Servidor API
El servidor API se ejecuta detrás del servicio kubernetes en el espacio de nombres default. Anote este servicio con la configuración 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 última anotación ad.datadoghq.com/endpoints.resolve es necesaria porque el servicio está frente a los pods estáticos. El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners. Los nodos en los que se están ejecutando pueden ser identificados con:
Se necesitan certificados para comunicarse con el servicio Etcd, que se encuentran en el host. Estos certificados deben montarse en los pods Cluster Check Runner agregando los volumes y volumeMounts como se indica a continuación.
Nota: También se incluyen montajes para deshabilitar el archivo de autoconfiguración de verificación de Etcd empaquetado con el agente.
Las ediciones directas de este servicio no se persisten, así que haga una copia del servicio Etcd:
oc get service etcd -n kube-system -o yaml | sed 's/name: etcd/name: etcd-copy/'| oc create -f -
Anote el servicio copiado con la configuración de verificación:
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'
El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners.
Controller Manager y Scheduler
El Controller Manager y el Scheduler se ejecutan detrás del mismo servicio, kube-controllers en el espacio de nombres kube-system. Las ediciones directas del servicio no se persisten, así que haga una copia del servicio:
oc get service kube-controllers -n kube-system -o yaml | sed 's/name: kube-controllers/name: kube-controllers-copy/'| oc create -f -
Anote el servicio copiado con las configuraciones de verificación:
El Datadog Cluster Agent programa las verificaciones como verificaciones de punto de conexión y las despacha a los Cluster Check Runners.
Kubernetes en Talos Linux
Helm es el método de instalación recomendado para Talos Linux. Utilice Helm configurando la bandera providers.talos.enabled a true.
Servidor API
La integración del servidor API se configura automáticamente. El Datadog Agent lo descubre automáticamente.
Etcd
Al proporcionar acceso de lectura a los certificados etcd ubicados en el host, la verificación del Datadog Agent puede comunicarse con etcd y comenzar a recopilar métricas de 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
Controller Manager y Scheduler
Puertos seguros
Los puertos seguros permiten la autenticación y autorización para proteger los componentes de su Plano de Control. El Datadog Agent puede recopilar métricas del Controller Manager y del Scheduler dirigiéndose a sus puertos seguros.
El campo ssl_verify en la configuración de kube_controller_manager y kube_scheduler necesita ser establecido en false al usar certificados autofirmados.
Al apuntar a puertos seguros, la opción bind-address en la configuración de tu Controller Manager y Scheduler debe ser accesible por el Datadog Agent. Aplique el parche a continuación a los nodos del plano de control en la generación del clúster; o, para nodos Talos en ejecución, ejecute talosctl patch mc -n <control-plane-node1,control-plane-node2> --patch @controlplane-datadog-monitoring-patch.yaml.
Rancher v2.5 se basa en PushProx para exponer los puntos finales de métricas del plano de control, lo que permite que el Datadog Agent ejecute verificaciones del plano de control y recopile métricas.
Agregue servicios de Kubernetes para configurar verificaciones de Autodiscovery
Al agregar servicios de Kubernetes sin cabeza para definir configuraciones de verificación, el Datadog Agent puede dirigirse a los pods pushprox y recolectar métricas.
Los componentes del plano de control se ejecutan en Docker fuera de Kubernetes. Dentro de Kubernetes, el servicio kubernetes en el espacio de nombres default apunta a la(s) IP(s) del nodo del plano de control. Puede confirmar esto ejecutando $ kubectl describe endpoints kubernetes.
Puede anotar este servicio con verificaciones de punto de conexión (gestionadas por el Datadog Cluster Agent) para monitorear el API Server, el Controller Manager y el Scheduler:
Etcd se ejecuta en Docker fuera de Kubernetes, y se requieren certificados para comunicarse con el servicio Etcd. Los pasos sugeridos para configurar la supervisión de Etcd requieren acceso SSH a un nodo del plano de control que ejecute Etcd.
Acceda por SSH al nodo del plano de control siguiendo la documentación de Rancher. Confirme que Etcd se está ejecutando en un contenedor Docker con $ docker ps, y luego use $ docker inspect etcd para encontrar la ubicación de los certificados utilizados en el comando de ejecución ("Cmd"), así como la ruta del host de los montajes.
Las tres banderas en el comando a buscar son:
--trusted-ca-file
--cert-file
--key-file
Usando la información de montaje disponible en la salida $ docker inspect etcd, configure volumes y volumeMounts en la configuración de Datadog Agent. También incluya tolerancias para que Datadog Agent pueda ejecutarse en los nodos del plano de control.
Los siguientes son ejemplos de cómo configurar el Datadog Agent con Helm y el Datadog Operator:
Configure un DaemonSet con un contenedor de pausa para ejecutar la verificación de Etcd en los nodos que ejecutan Etcd. Este DaemonSet se ejecuta en la red del servidor para que pueda acceder al servicio de Etcd. También tiene la configuración de verificación y las tolerancias necesarias para ejecutarse en el(los) nodo(s) del plano de control. Asegúrese de que las rutas de los archivos de certificado montados coincidan con lo que configuró en su instancia y reemplace la parte <...> en consecuencia.
Para desplegar el DaemonSet y la configuración de verificación, ejecute
kubectl apply -f <filename>
Kubernetes en servicios administrados (AKS, GKE)
En otros servicios administrados, como Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE), el usuario no puede acceder a los componentes del plano de control. Como resultado, no es posible ejecutar las verificaciones kube_apiserver, kube_controller_manager, kube_scheduler o etcd en estos entornos.
1
2
rulesets:- %!s(<nil>) # Rules to enforce .
Solicitar una demostración personalizada
Empezando con Datadog
Datadog Docs AIYour use of this AI-powered assistant is subject to our Privacy Policy. Please do not submit sensitive or personal information.
