El objetivo de esta sección es documentar las especificidades y proporcionarte buenas configuraciones de base para la monitorización de planos de control de Kubernetes. Luego, podrás personalizar estas configuraciones para añadir cualquier característica de Datadog.
Al proporcionar acceso de lectura a los certificados de Etcd ubicados en el host, el check del Datadog Agent puede comunicarse con Etcd y empezar a recopilar métricas de Etcd.
Si los puertos inseguros de tus instancias del administrador de controladores y del programador están habilitados, el Datadog Agent detecta las integraciones y comienza a recopilar métricas sin ninguna configuración adicional.
Los puertos seguros permiten la autenticación y autorización para proteger los componentes de tu plano de control. El Datadog Agent puede recopilar métricas del administrador de controladores y del programador dirigiéndose a sus puertos seguros.
El campo ssl_verify de kube_controller_manager y la configuración de kube_scheduler deben establecerse en false cuando se utilizan certificados auto-firmados.
Cuando se dirige a puertos seguros, la opción bind-address en la configuración de tu administrador de controladores y de tu programador debe ser accesible por el Datadog Agent. Por ejemplo:
El servidor de 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 se encuentra delante de pods estáticos. El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a ejecutadores de checks de clústeres. Los nodos en los que se están ejecutando se pueden identificar con:
Los certificados son necesarios para comunicarse con el servicio Etcd, que se puede encontrar en el secreto kube-etcd-client-certs, en el espacio de nombres de openshift-monitoring. Para brindar acceso al Datadog Agent a estos certificados, primero hay que copiarlos 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 del ejecutador de checks de clústeres añadiendo los volúmenes y los montajes de volúmenes como se indica a continuación.
Nota: También se incluyen montajes para desactivar el archivo de auto-configuración del check de Etcd empaquetado con el Agent.
El administrador de controladores se ejecuta detrás del servicio kube-controller-manager, en el espacio de nombres de openshift-kube-controller-manager. Anota este servicio con la configuración del check:
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 los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres.
El programador se ejecuta detrás del servicio scheduler, en el espacio de nombres de openshift-kube-scheduler. Anota este servicio con la configuración del check:
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 los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres.
El servidor de 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á delante de pods estáticos. El Datadog Cluster Agent programa los checks como checks de endpoints y los envía a los ejecutadores de checks de clústeres. Los nodos en los que se están ejecutando se pueden identificar con:
Los certificados son necesarios para comunicarse con el servicio Etcd que se encuentra en el host. Estos certificados deben montarse en los pods del ejecutador de checks de clústeres añadiendo los volúmenes y montajes de volúmenes como se indica a continuación.
Nota: También se incluyen montajes para desactivar el archivo de auto-configuración del check de Etcd empaquetado con el Agent.
El administrador de controladores y el programador se ejecutan detrás del mismo servicio, kube-controllers, en el espacio de nombres de kube-system. Las ediciones directas del servicio no se conservan, así que haz 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 -
Anota el servicio copiado con la configuración del check:
Rancher v2.5 se basa en PushProx para exponer endpoints de métricas del plano de control, lo que permite al Datadog Agent ejecutar checks del plano de control y recopilar métricas.
Al añadir servicios Kubernetes headless para definir configuraciones de checks, el Datadog Agent puede dirigirse a los pods pushprox y recopilar 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 se dirige a la(s) IP(s) del nodo del plano de control. Puedes confirmarlo ejecutando $ kubectl describe endpoints kubernetes.
Puedes anotar este servicio con checks de endpoints (gestionados por el Datadog Cluster Agent) para monitorizar el servidor de API, el administrador de controladores y el programador:
Etcd se ejecuta en Docker fuera de Kubernetes y se necesitan certificados para comunicarse con el servicio Etcd. Los pasos sugeridos para configurar la monitorización de Etcd requieren acceso SSH a un nodo del plano de control que ejecute Etcd.
Consulta el acceso SSH al nodo del plano de control en la documentación de Rancher. Confirma que Etcd se está ejecutando en un contenedor de Docker con $ docker ps y luego utiliza $ docker inspect etcd para encontrar el localización de los certificados utilizados en el comando de ejecución ("Cmd"), así como la ruta del host de los montajes.
Las tres marcas que debes buscar en el comando son:
--trusted-ca-file
--cert-file
--key-file
Utilizando la información de montaje disponible en la salida $ docker inspect etcd, configura volumes y volumeMounts en la configuración del Datadog Agent. Incluye también tolerancias para que el 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:
Configura un DaemonSet con un contenedor pausado para ejecutar el check de Etcd en los nodos que ejecutan Etcd. Este DaemonSet se ejecuta en la red del host para que pueda acceder al servicio Etcd. También tiene la configuración del check y las tolerancias necesarias para ejecutarse en el(los) nodo(s) del plano de control. Asegúrate de que las rutas de los archivos de certificados montados coinciden con lo que has configurado en su instancia y reemplaza la parte <...> en consecuencia.
En otros sistemas gestionados 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 los checks de kube_apiserver, kube_controller_manager, kube_scheduler o etcd en estos entornos.
