Tweak some settings for better Prometheus metrics access. #160
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.
These are essentially the changes documented in kube-prometheus-on-kubeadm.md. They enable Prometheus running in Kubernetes to scrape container-level metrics from each Kubelet (authenticating with a ServiceAccount token)
and to scrape metrics from.kube-controller-manager
andkube-scheduler
(anonymously)These have some tradeoffs that we should discuss. Thekube-controller-manager
andkube-scheduler
--address
changes mean that they will expose metrics over these endpoints to the whole cluster.These metrics aren't super sensitive but they do give away some context about where the cluster is running, the versions of the components, and some high level picture of what's running in the cluster. I think this is acceptable for most use cases where the Quick Start is appropriate today.There is recent work upstream (kubernetes/kubernetes#59582) that will add authentication options for these endpoints.Update
I dropped the
--address
changes and left only the Kubelet authentication flag change.