Currently the cluster-authentication-operator (CAO) checks that all endpoints of the kube apiserver service are properly serving the well-known endpoint. However, the set of endpoints may not represent all apiservers running in a cluster in some instances (e.g. after initial install). In those cases, a cluster with 3 masters and therefore 3 desired apiservers may only have 2 endpoints for the service while the cluster-kube-apiserver-operator is progressing to bring the 3rd apiserver online. The CAO needs to not report available until the well-known endpoint is checked on all expected apiservers.
While the suggestion in the slack discussion that prompted this filing seemed to be that the CAO should be responsible for determining whether it was checking the well-known endpoint on the desired count of apiservers, I wonder if the cluster-kube-apiserver-operator shouldn't be reporting the number of intended replicas in its status for consumption by CAO and others rather than requiring the CAO to derive that number itself (e.g. by counting master nodes).
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