4

According to https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#scaling-a-statefulset, I would like to ask how to achieve zero-downtime rolling update? I guess here are the minimum requirements:

(1) .spec.updateStrategy set to RollingUpdate

(2) .spec.podManagementPolicy set to OrderedReady

(3) .spec.replicas set to 2

Is that right? And I assume that when update is happening in reverse order, all traffic to the StatefulSet is served by the pods with lower ordinal number?

Kok How Teh
  • 1,531
  • 1
  • 21
  • 48

2 Answers2

4

Yes to have have zero downtime for statefulsets upgrade, you should have all the points mentioned:

  1. .spec.updateStrategy set to RollingUpdate
  2. .spec.podManagementPolicy set to OrderedReady which is by default OrderedReady
  3. .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.

Prafull Ladha
  • 8,502
  • 1
  • 21
  • 42
  • 1
    Please go through following link to understand how to do zero downtime upgrade https://medium.com/platformer-blog/enable-rolling-updates-in-kubernetes-with-zero-downtime-31d7ec388c81 – Prafull Ladha Jan 23 '19 at 13:44
  • These parameters are only applicable to Deployment. Not StatefulSet. – Kok How Teh Jan 24 '19 at 09:09
  • I have updated my answer. You can use readiness probe in statefulset also. I have added snippet which I use for upgrade my statefulsets – Prafull Ladha Jan 24 '19 at 09:15
  • According to https://github.com/ubuntu/microk8s/issues/294, those parameters are not for StatefulSet, only for Deployment..? – Kok How Teh Jan 24 '19 at 09:25
  • You can not set `maxUnavailable` and `maxSurge` parameter in rollingupdate strategy are not for statefulsets. The parameter I mentioned in readiness probe are present for statefulsets. – Prafull Ladha Jan 24 '19 at 09:35
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/187241/discussion-between-prafull-ladha-and-kok-how-teh). – Prafull Ladha Jan 24 '19 at 09:37
  • No, readiness probe params are also not available for statefulsets...:( – Kok How Teh Feb 12 '19 at 09:44
  • Hi, sorry the params are available. I made a mistake in the indentations of the params that caused the syntax error. – Kok How Teh Feb 24 '19 at 06:18
  • Now, did you tried upgrading the rolling update of statefullsets using the readiness parameter, so that if statefulsets will be upgrading replicas one by one and start the next replica only if the previous upgraded replica is ready to serve requests – Prafull Ladha Feb 24 '19 at 06:21
  • It still doesn't work due to this bug: https://github.com/kubernetes/kubernetes/issues/74456 Do you have the same issue? – Kok How Teh Feb 24 '19 at 08:39
1

I agree with @Prafull Ladha, the main role of readinessProbe here to guarantee that the new pods created during RollingUpdate are ready to take on requests before terminating the old pods. However, you can also control the rolling update process by specifying the appropriate optional parameters as described in official Kubernetes documentation.

Nick_Kh
  • 4,098
  • 2
  • 5
  • 13
  • 1
    These parameters are only applicable to Deployment. Not StatefulSet. – Kok How Teh Jan 24 '19 at 09:08
  • yeah, you are right for statefulsets it's not applicable, just only [Partitions](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#partitions) . – Nick_Kh Jan 25 '19 at 09:08