We see these for request from kube-apiserver to itself before it is ready. They are confusing for the user and noise in debugging: Loopback request to %q (user agent %q) before server is ready. This client probably does not watch /readyz and might get inconsistent answers.
Without fix build, $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.6.0-0.nightly-2020-09-28-212756 True False 27h Cluster version is 4.6.0-0.nightly-2020-09-28-212756 $ oc logs -n openshift-kube-apiserver kube-apiserver-ip-10-0-145-89.us-east-2.compute.internal -c kube-apiserver | grep 'user agent "kube-apiserver' | wc -l 205 Verified with loaded fix build, $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.6.0-0.nightly-2020-09-29-170625 True False 3h48m Cluster version is 4.6.0-0.nightly-2020-09-29-170625 $ oc logs -n openshift-kube-apiserver kube-apiserver-ip-10-0-157-18.us-east-2.compute.internal -c kube-apiserver | grep 'user agent "kube-apiserver' | wc -l 0 We can see there is no Loopback request from user agent "kube-apiserver" logged as expected, so move the bug verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4196