+++ 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.