These metrics are superseded by the Pod resource metrics initiative in
Kubernetes. In 2.0.0, we removed the reworked container resource
metrics, but omitted the init container ones although they are also
covered by the Kubernetes effort.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
use clientgofix library
add context parameter in verticalpodautoscaler
rename PodDisruptionsAllowed to DisruptionsAllowed because of PR 85863 in k8s repo
lint fixes and rename PodDisruptionsAllowed to DisruptionsAllowed in test file
run go mod tidy
Fixes#979
test:store - Updates unit test to reflect removal of 'node' name from labels
test: Update main_test for removal of node label from pod metrics
Aim of this PullRequest is to add several new pod metrics:
- kube_pod_deleted: Unix deletion timestamp
- kube_pod_status_reason: The pod status reasons (NodeLost, Evicted)
These new metrics can be used to determine the `pod.status.phase`
displayed by `kubectl`: Running, Terminated, Unknown…
It will allow removing the `kubectl` display logic added previously
to compute the “Unknown” phase.
Signed-off-by: cedric lamoriniere <cedric.lamoriniere@datadoghq.com>
This commit introduces the fact that build.WithGenerateStoreFunc()
needs to be used for configuring properly the `Builder` (like any other
`With...` method.
* rename: `WithCustomGenerateStoreFunc` to `WithGenerateStoreFunc`.
* remove buildStorFunc defaulting in `NewBuilder()` function
* add `DefaultGenerateStoreFunc()` method in `BuilderInterface`
* update `Builder initialisation` in `main.go`
Signed-off-by: cedric lamoriniere <cedric.lamoriniere@datadoghq.com>
main_test.go: Add model based test for sharding
In order to ensure a sharded system behaves equal to an unsharded
system, a model based test has been introduced. It scrapes an unsharded
setup and compares its output with the union of a sharded setup
therefore ensuring semantic equality.
When kube-state-metrics does not have the correct roles to list or watch
on a resource, it just logs this error but not actually error out. This
is a problem as the pod never restars and it is hard to catch any
problems as other resource metrics continue to be created correctly. We
only see this error in the noisy kube-state-metrics logs.
This registers two metrics `kube_state_metrics_watch_total` and
`kube_state_metrics_list_total`. With the following labels:
"result" label is the type of action count relates to, error or success.
"resource" label contains the resource <apiVersion.Kind>.
This way we can do a rate alert when kube-state-metrics error rate is
too high.
Example of the metrics:
kube_state_metrics_list_total{resource="*v1.Namespace",result="success"} 1
kube_state_metrics_list_total{resource="*v1.Node",result="error"} 52
kube_state_metrics_watch_total{resource="*v1beta1.Ingress",result="success"} 1