As already mentioned in this issue https://github.com/kubernetes/kubernetes/issues/79286, some metrics like
"running_pod_count" and "running_container_count" uses non-standard prometheus metrics, this change converts them to be
standard prometheus gauges
Minor refactor in kubelet/pleg/generic.go and added some test for ruuning container and running pod metrics
Fixed issues related to github CI pipeline failure
* Updated bazel for new deps
* Add comment for exported metrics variables,RuuningContainerCount and RunningPodCount
* Specify keys explicitly in Guage metric instantation
Fix go lint errors
Replace "+=1" with "++", as reported by go lint
Set container state as a label for the metrics "running_container_count"
As per the metrics name "running_container_count" it should "ideally" be showing
the number of containers in "running" state , but it was showing all the container count, irrespective of the state it is in.
This commit adds a new label "container_running_state" to the metrics "running_container_count", which doesn't change the base metrics but adds the
option to query the metrics with "container_state" such as "running"/"unknown/...
remove unused methods reported by staticcheck
Remove variables while instantiating gauge(vec) which are default set to nil
Convert kubelet metrics(running_pod_count and running_container_count) to standard gauges and added label to running_container_count metrics.
Currently kubelet metrics(running_pod_count and running_container_count) use non-standard prometheus collectors , this change
converts them to standard prometheus gauges. Also this adds a new label(container_state) to running_container_count which does a breakdown of
containers tracked by kubelet based on the containers' state(running/unknown/created/exited).
Set statbility explicitly for running_pod_count and running_container_count and reformat test
register metrics explicitly in test , so that they don't become no-op
This commit fills out the JWT "kid" (KeyID) field on most
serviceaccount tokens we create. The KeyID value we use is derived
from the public key of keypair that backs the cluster's OIDC issuer.
OIDC verifiers use the KeyID to smoothly cope with key rotations:
* During a rotation, the verifier will have multiple keys cached
from the issuer, any of which could have signed the token being
verified. KeyIDs let the verifier pick the appropriate key
without having to try each one.
* Seeing a new KeyID is a trigger for the verifier to invalidate its
cached keys and fetch the new set of valid keys from the identity
provider.
The value we use for the KeyID is derived from the identity provider's
public key by serializing it in DER format, taking the SHA256 hash,
and then urlsafe base64-encoding it. This gives a value that is
strongly bound to the key, but can't be reversed to obtain the public
key, which keeps people from being tempted to derive the key from the
key ID and using that for verification.
Tokens based on jose OpaqueSigners are omitted for now --- I don't see
any way to actually run the API server that results in an OpaqueSigner
being used.
