We’ve observed that when using WithAuthenticationAndAuthorization() (with self-signed certs), the metrics server may take a few seconds to become available on Kubernetes 1.33+.
In particular, some Kubebuilder tests started failing against 1.33, where they were still passing in previous versions < 1.33. After debugging, the root cause seems to be a delay related to how Kubernetes 1.33 handles token availability and cert readiness, likely due to changes in the API server behaviour.
To solve our tests for 1.33+ we added a delay: https://github.com/kubernetes-sigs/kubebuilder/pull/4882/files
Just an Idea
It might be nice if controller-runtime could provide a ReadyzCheck for the metrics server. That would help in scenarios using either self-signed or provided certs, by allowing consumers to verify the /metrics endpoint is actually ready (serving over HTTPS and accepting tokens) before probing or testing.
Thanks for your work and for considering this 🙌
We’ve observed that when using
WithAuthenticationAndAuthorization()(with self-signed certs), the metrics server may take a few seconds to become available on Kubernetes 1.33+.In particular, some Kubebuilder tests started failing against 1.33, where they were still passing in previous versions < 1.33. After debugging, the root cause seems to be a delay related to how Kubernetes 1.33 handles token availability and cert readiness, likely due to changes in the API server behaviour.
To solve our tests for 1.33+ we added a delay: https://github.com/kubernetes-sigs/kubebuilder/pull/4882/files
Just an Idea
It might be nice if
controller-runtimecould provide aReadyzCheckfor the metrics server. That would help in scenarios using either self-signed or provided certs, by allowing consumers to verify the/metricsendpoint is actually ready (serving over HTTPS and accepting tokens) before probing or testing.Thanks for your work and for considering this 🙌