Yes to have have zero downtime for statefulsets upgrade, you should have all the points mentioned:
.spec.updateStrategy set to RollingUpdate
.spec.podManagementPolicy set to OrderedReady which is by default OrderedReady
.spec.replicas set to minimum 2.
Another, thing you need to make sure your statefulset doesn't have downtime is proper readiness probe set. The readiness probe tells kubernetes controller manager that this pod is ready to serve request and you can start sending the requests to it.
The reason it is very important while doing zero downtime upgrade is lets say you have two replica's of statefulset and you started rolling upgrade without readiness probe set. The kubernetes will delete the pod in reverse order and make it come to running state and mark it as ready and terminate another pod. Now lets say your container process didn't come up in that time there will be no pod to serve the requests, because one pod is not completely ready yet and kubernetes has terminated another pod for upgrade process and hence the data loss.
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 1
EDIT: The following json snippet I use for rolling update of statefulsets in my case:
"spec": {
"containers": [
{
"name": "md",
"image": "",
"imagePullPolicy": "IfNotPresent",
"command": [
"/bin/sh",
"-c"
],
"args": [
"chmod -R 777 /logs/; /on_start.sh"
],
"readinessProbe": {
"exec": {
"command": [
"cat",
"/tmp/ready.txt"
]
},
"failureThreshold": 10,
"initialDelaySeconds": 5,
"periodSeconds": 5,
"successThreshold": 1,
"timeoutSeconds": 1
},
"securityContext": {
"privileged": true
}
}
This is how you can setup readiness probe in your statefulset containers. I am setting readiness probe as linux command, if you have http probe then it will be different.