-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
4.13.z, 4.14.z, 4.15.z, 4.17.z, 4.16.z, 4.18.0
-
None
-
Moderate
-
None
-
False
-
Description of problem:
The .status.readyReplicas is always 0 for cluster operators, like kubeapiserver.operator / authentication.operator / openshiftapiserver.operator / etcd.operator / kubecontrollermanager.operator / kubescheduler.operator, even if their operands ready replicas are indeed positive numbers.
Version-Release number of selected component (if applicable):
Latest 4.13 ~ 4.18 available payloads
How reproducible:
Always
Steps to Reproduce:
1 Check the operator's .status.readyReplicas, it is always 0: $ oc get kubeapiserver.operator cluster -o yaml | grep -A 1000 "^status:" status: conditions: ... readyReplicas: 0 ... 2 Though the operand ready replicas are 3: $ oc get po -n openshift-kube-apiserver -L revision -l apiserver NAME READY STATUS RESTARTS AGE REVISION kube-apiserver-ip-10-0-145-156.us-east-2.compute.internal 5/5 Running 0 8h 7 kube-apiserver-ip-10-0-188-40.us-east-2.compute.internal 5/5 Running 0 8h 7 kube-apiserver-ip-10-0-193-122.us-east-2.compute.internal 5/5 Running 0 8h 7
Actual results:
The .status.readyReplicas is always 0 though the actual operand ready replicas are 3. Checking other operators like authentication.operator / openshiftapiserver.operator / etcd.operator / kubecontrollermanager.operator / kubescheduler.operator, all show same issue.
Expected results:
Users should not be confused by above the field's actual results given the field's meaning is clear:
$ oc explain kubeapiserver.status.readyReplicas
...
DESCRIPTION:
readyReplicas indicates how many replicas are ready and at the desired state
Additional info: