Cuando la opción principal está activada, sólo esta proporciona configuraciones de check de clúster a los Agents basados en nodos. Si sólo se está ejecutando una réplica del pod del Cluster Agent, esta será la opción principal. En caso contrario, puedes identificar el nombre de la opción principal en el ConfigMap datadog-leader-election:
# kubectl get cm datadog-leader-election -o yamlapiVersion:v1kind:ConfigMapmetadata:annotations:control-plane.alpha.kubernetes.io/leader:'{"holderIdentity":"cluster-agent-rhttz", ... }'
En este caso, el pod principal es cluster-agent-rhttz. Si el pod se borra o no responde, otro pod toma el relevo automáticamente.
Para asegurarte de que el Cluster Agent selecciona una configuración (estática o de Autodiscovery), utiliza el comando configcheck en el Cluster Agent principal:
Nota: El ID de instancia es diferente del comando configcheck, ya que la instancia se modifica para añadir etiquetas (tags) y opciones.
En este caso, esta configuración se distribuye al nodo default-pool-bce5cd34-ttw6. En cuanto al pod del Agent, la solución de problemas continúa en ese nodo en particular.
Solucionar problemas de los checks de endpoints es similar a solucionar problemas de los checks de clústeres. Las diferencias se producen en los Agents de nodo, donde los checks de endpoints programados aparecen junto a los checks de clústeres.
Nota: Los checks de endpoints los programan los Agents que se ejecutan en el mismo nodo que el/los pod(s) que respalda el endpoint (o endpoints) del servicio. Si un endpoint no está respaldado por un pod, el Cluster Agent convierte el check en un check de clúster. Este check de clúster lo puede ejecutar cualquier Agent de nodo.