Lorsque l’élection de leader est activée, seul le leader distribue les configurations de check de cluster aux Agents de nœud. Si un seul réplica du pod de l’Agent de cluster est exécuté, il s’agit du leader. Si vous exécutez plusieurs réplicas, vous pouvez identifier le nom du leader dans la ConfigMap de datadog-leader-election :
# kubectl get cm datadog-leader-election -o yamlapiVersion:v1kind:ConfigMapmetadata:annotations:control-plane.alpha.kubernetes.io/leader:'{"holderIdentity":"cluster-agent-rhttz", ... }'
Ici, le pod leader est cluster-agent-rhttz. S’il est supprimé ou ne répond pas, un autre pod le remplace automatiquement.
Pour garantir la récupération d’une configuration (statique ou identifiée avec Autodiscovery) par l’Agent de cluster, utilisez la commande configcheck dans l’Agent de cluster leader :
Remarque : l’ID d’instance est différent de celui de la commande configcheck, car l’instance est modifiée pour ajouter des tags et des options.
Dans le cas présent, cette configuration est distribuée au nœud default-pool-bce5cd34-ttw6. Le dépannage du pod de l’Agent se poursuit sur le nœud correspondant.
Le dépannage de checks d’endpoint est semblable au dépannage de checks de cluster. Les principales différences se situent au niveau des Agents de nœud. Pour ces Agents, les checks d’endpoint planifiés apparaissent aux côtés des checks de cluster.
Remarque : les checks d’endpoint sont planifiés par des Agents qui s’exécutent sur le même nœud que le ou les pods qui exposent le ou les endpoints du service. Si un endpoint n’est pas exposé par un pod, l’Agent de cluster convertit le check en check de cluster. Le check de cluster peut être exécuté par n’importe quel Agent de nœud.