-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
4.12
-
Moderate
-
No
-
3
-
OSDOCS Sprint 237, OSDOCS Sprint 238
-
2
-
False
-
-
N/A
-
Release Note Not Required
-
Description of problem:
Include statefulsets description and its behavior during a node NotReady state. As of now there are no much data available about the Statefulsets and its default behavior in the official OCP documentation. Business Impact: - CU recently had an issue with the nodes where the nodes went to NotReady state and the statefulsets didn't actually rescheduled. - According to the Official Openshift documentation the pods should reschedule to another working node once the tolerationtime in seconds are finished according to the documentation here[0] - But there is some manual intervention required to get the pods evicted and to get rescheduled into other nodes in case of Statefulsets and itsan expected behavior. - We have already this[1] upstream doc and a KCS[2] which actually describes the same and are the fundamental behavior of the same. - But it would be great if we could add the same as a note in the OCP documentation[0] as it already includes the information for the daemon-sets pods behavior [0] https://docs.openshift.com/container-platform/4.12/nodes/scheduling/nodes-scheduler-taints-tolerations.html#nodes-scheduler-taints-tolerations-about-taintBasedEvictions_nodes-scheduler-taints-tolerations [1] https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/#delete-pods [2] https://access.redhat.com/solutions/4254721
Version-Release number of selected component (if applicable):
4.12
How reproducible:
- Run a statefulset deployment - Make a node notReady where one of the statefulset pod runs - The statefulset pod will not automatically reschedule to another node - We may need to manually remove the pod which is marked for deletion and then reschedule it
Steps to Reproduce:
1. 2. 3.
Actual results:
The STS pods are not rescheduled to a working node without manual interventions.
Expected results:
Need to add the same into the documentation that this is the expected behavior in case of STS pods!
Additional info:
Reference Case: 03460040