+++ This bug was initially created as a clone of Bug #1851389 +++ kcm pod crashloops because port is already in use. I saw a case with cluster-policy-manager container but it's not limited to it. Crashlooping triggers alerts and adds backoff for the pod so it start slower. Container can be restarted while the pods stays. For that reason, we need to check the port availability in the same process as we listen, not in an init container which isn't re-run.
$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.5.0-0.nightly-2020-07-20-152128 True False 108m Error while reconciling 4.5.0-0.nightly-2020-07-20-152128: the cluster operator kube-controller-manager is degraded $ oc exec -n openshift-vsphere-infra haproxy-scheng-45-tqgsd-master-0 -- cat /etc/haproxy/haproxy.cfg | grep bind Defaulting container name to haproxy. Use 'oc describe pod/haproxy-scheng-45-tqgsd-master-0 -n openshift-vsphere-infra' to see all of the containers in this pod. bind :::9443 v4v6 The haproxy occupied the port 9443, kcm always restarted $ oc get pods -A |awk '$5 >10' NAMESPACE NAME READY STATUS RESTARTS AGE openshift-kube-controller-manager kube-controller-manager-scheng-45-tqgsd-master-0 4/4 Running 18 121m openshift-kube-controller-manager kube-controller-manager-scheng-45-tqgsd-master-1 3/4 CrashLoopBackOff 21 120m openshift-kube-controller-manager kube-controller-manager-scheng-45-tqgsd-master-2 3/4 CrashLoopBackOff 18 120m
Above problem was tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1858498
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, 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:2956