Prior to this fix, openapi spec for prometheus-adapter apiextension was based on the type "k8s.io/sample-apiserver/pkg/apiserver" which is incorrect. Due to the incorrect type, `kubectl explain podmetrics` (or nodemetrics) wasn't showing any doc for any resources from metrics.k8s.io/v1beta1.
This changeset fixes the problem by using the right type(sigs.k8s.io/metrics-server/pkg/api) for the openapi generation.
This also helped to remove the sample-apiserver dependency from
prometheus-adapter.
Signed-off-by: Arunprasad Rajkumar <arajkuma@redhat.com>
Create the pod lister based on a filtered informer factory that will
filter non-running pods so that prometheus-adapter don't expect metrics
from them.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Add a signal handler stopping the adapter if it receives a SIGINT or
SIGTERM signal. This prevent the prometheus-adapter pod from being stuck
in "Terminating" state.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Pick up changes to 1.17 to custom-metrics-apiserver and the latest
changes in metrics-server to allow us to show table results for
podmetrics and nodemetrics. Fix import and interface changes as
necessary.
The localvendor directory is an artifact of a change in sigs.k8s.io:
sigs.k8s.io/metrics-server now requires this dependency in order to
resolve, even though we do not use the scraper package.
go: sigs.k8s.io/metrics-server@v0.3.7 requires
k8s.io/kubernetes/pkg/kubelet/apis/stats/v1alpha1@v0.0.0: reading k8s.io/kubernetes/pkg/kubelet/apis/stats/v1alpha1/pkg/kubelet/apis/stats/v1alpha1/go.mod at revision pkg/kubelet/apis/stats/v1alpha1/v0.0.0: unknown revision pkg/kubelet/apis/stats/v1alpha1/v0.0.0
Often prometheus is gated by some proxy requiring an auth bearer
token. Currently there is no possibility to configure one except for
providing a full-fledged kubeconfig.
This fixes it by adding a new flag pointing to an optional file
containing the auth bearer for prometheus communication.
This disables the custom metrics API when no custom metrics rules are
given (the resource metrics API acts equivalently). This allows a given
adapter to serve only one of the APIs, if desired.
This introduces support for the resource metrics in the adapter.
The individual queries and window sizes are fully customizable via a new
config section. This uses just the generic machinery from
metrics-server to serve the API.
