The new etcd balancer (>3.3.14, 3.4.0) uses an asynchronous resolver for
endpoints. Without "WithBlock", the client may return before the
connection is up.
Signed-off-by: Gyuho Lee <leegyuho@amazon.com>
The new etcd balancer (>3.3.14, 3.4.0) uses an asynchronous resolver for
endpoints. Without "WithBlock", the client may return before the
connection is up.
Signed-off-by: Gyuho Lee <leegyuho@amazon.com>
The new etcd balancer (>3.3.14, 3.4.0) uses an asynchronous resolver for
endpoints. Without "WithBlock", the client may return before the
connection is up.
Signed-off-by: Gyuho Lee <leegyuho@amazon.com>
The new etcd balancer (>3.3.14, 3.4.0) uses an asynchronous resolver for
endpoints. Without "WithBlock", the client may return before the
connection is up.
Signed-off-by: Gyuho Lee <leegyuho@amazon.com>
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
The previously existing e2e GMSA test really only tests a small part of the
whole GMSA set up process, namely that once the API has inlined the GMSA
contents in the pod's spec, and sent that to a worker's kubelet, then the
kubelet passes that down to the runtime.
This new test, in contrast, really tests the whole thing, i.e. deploying the
admission webhook, then deploying a GMSA custom resource, and using that
resource within a pod.
The downside of this test though, is that it does need to make a lot of
assumptions about the cluster it runs against, notably that it runs on a worker
node that's already been joined to a working Active Directory domain (there are
other assumptions, all documented at the beginning of the test file); for that
reason, it is only intended to ever be run against an AKS cluster with the
custom AKS extension from
https://github.com/kubernetes-sigs/windows-testing/pull/98.
Note that this test doesn't aim at testing every edge-case, such as
a pod trying to use a GMSA it doesn't have access to; the webhook has
its own tests for these. This test's goal is to ensure the happy path
doesn't break.
Signed-off-by: Jean Rouge <rougej+github@gmail.com>
The "system_node_critical_test" causes DiskPressure on the node,
resulting in eviction of some of the pre pulled images. This makes all
the resulting tests to fail, since their pod spec use PullPolicy: Never
The PrePullImages is now inside a defer, so it will be executed even tho
the assertions inside the "AfterEach" fail.
