Fix auto-discovery for latest versions on Kubernetes #9574
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Leverages the
possible_prometheus_urls
parameter introduced by #9573 in the auto-discovery configuration file.Motivation
Make the agent able to automatically monitor the Kube scheduler on most recent versions of Kubernetes without requiring too much user setup.
The goad is to simplify the Kubernetes control plane monitoring setup described in DataDog/documentation#10828.
Additional Notes
On older versions of Kubernetes, the Kube scheduler metrics were available at
http://%%host%%:10251/metrics
where%%host%%
is the node IP.On most recent version of Kubernetes,
https
endpoint is available by default. The plainhttp
endpoint is disabled by default.127.0.0.1
instead of being remotely available.The new auto-discovery configuration will try the combination of different settings to find a usable Kube scheduler metrics endpoint.
The only thing that the end-user will still need to do to get this check working is:
hostNetwork: true
on its agent to be able to use the127.0.0.1
IP, or0.0.0.0
as already described in K8s control plane docs documentation#10828.Kubernetes exposes in the pods only the certificates needed to talk to the API server.
There is no reliable way to get the CA certificate used by the Kube scheduler that would work on every distribution. In particular, at least
minikube
andkubeadm
are using self-signed certificates.That’s why
ssl_verify: false
is required.Review checklist (to be filled by reviewers)
changelog/
andintegration/
labels attached