New kube-apiserver-operator webhook controller validating health of webhook in OpenShift Container Platform 4

Issue

• What's the rational for an operator calling directly webhooks, without going through the API? We see kube-apiserver-operator trying to access configured webhooks after updating to OCP 4.10. As we have NetworkPolicies for the namespace hosting the webhook it's not possible to reach them from kube-apiserver-operator hence seeing the following logs:

  $ oc logs -n openshift-kube-apiserver-operator deploy/kube-apiserver-operator
  [...]
  E0622 13:54:11.540867       1 degraded_webhook.go:128] dial tcp 10.1.1.249:443: i/o timeout
  E0622 13:54:13.541971       1 degraded_webhook.go:128] dial tcp 10.1.1.249:443: i/o timeout
  E0622 13:54:17.544072       1 degraded_webhook.go:128] dial tcp 10.1.1.249:443: i/o timeout
  E0622 13:54:19.544769       1 degraded_webhook.go:128] dial tcp 10.1.1.249:443: i/o timeout
  E0622 13:54:23.561043       1 degraded_webhook.go:128] dial tcp 10.1.1.101:443: i/o timeout
  E0622 13:54:25.562466       1 degraded_webhook.go:128] dial tcp 10.1.1.101:443: i/o timeout