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.