This will let us preinstall the Stackdriver logging agent but still
configure it correctly when bringing up new Windows nodes.
The hostname in the config file looks the same before-and-after:
"logging.googleapis.com/local_resource_id" ${"k8s_node.e2e-test-peterhornyack-windows-node-group-6tw6"}
"logging.googleapis.com/local_resource_id" ${"k8s_node.e2e-test-peterhornyack-windows-node-group-mf5r"}
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>