<p>Use a combination of <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes" rel="noreferrer">Readiness Probes</a> and a proper deployment strategy.</p>
<ol>
<li>Configure your Deployment spec like so:
<pre><code>spec:
  replicas: 4    # or as many as you need to have
  strategy:
    rollingUpdate:
  maxUnavailable: 0
  maxSurge: 1
</code></pre>
<code>maxUnavailable</code> = 0 means that there should always be a number of pods available equal to the <code>replicas</code> count. <code>maxSurge</code> = 1 means that kubernetes will create the new pods one at a time, and destroy the old ones one-at-a-time as well.</li>
<li>Implement a <code>readinessProbe</code> which should return a successful response when the database migration has completed. You'd have to write the logic for that yourself, but if you do it right, kubernetes will create a pod with the new Deployment and wait for it to complete and only after that, evict 1 of the old ones.</li>
</ol>
<p>PS: It's worth noting that this approach will cause your node to temporarily contain more pods than your <code>replicas</code> config implies, namely <code>replicas + 1</code> for a short period of time while deploying. You need to make sure that your node can handle the little extra load untill the rollout is complete.</p>

CC BY-SA 4.0
2020-10-20T12:19:15.967Z
2020-10-20T15:30:42.303Z
2020-10-20T15:30:42.303Z
kalatabe
<p>Here you could create a lock table inside your database, then the first pod would take the lock and then run the update. Other pods startup scripts would wait for the lock to be released before starting the application. A simpler solution is to run a pod inside a job for upgrading the database before launching the application.</p>

CC BY-SA 4.0
2020-10-19T17:44:54.770Z
2020-10-19T17:44:54.770Z
Fabrice Jammes
<p>I think you can create init container</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      initContainers:
      - name: db-migration
        image: my-db-migration-image:latest
        command: [&quot;sh&quot;, &quot;-c&quot;, &quot;run-migration-script.sh&quot;]
        env:
        - name: DATABASE_URL
          value: &quot;your-database-url&quot;
      containers:
      - name: my-app-container
        image: my-app-image:latest
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
</code></pre>

CC BY-SA 4.0
2024-11-28T10:38:36.497Z
2024-11-28T10:38:36.497Z
Qodirov Shohijahon
<p>Is it possible to tell kubernetes, that when performing a deployment of multiple pods that it should start only one at a time and only create the next pod if the previous has completely started up?</p>
<p>It would be useful in our usecase:
Our application automatically migrates/upgrades the database when starting up. But when there are multiple pods starting up at the same time, it could happen that multiple pods try to upgrade the database at the same time which could corrupt the database.</p>
<p>But if kubernetes would wait with starting up the second pod until the first pod has fully started up, it would mean that the database has been correctly upgraded by then.</p>
<p>If kubernetes does not have such functionality, how would you handle such a case?</p>

<kubernetes>
Start only one pod at a time in kubernetes
Van Coding
# Start only one pod at a time in kubernetes

(Asked by: username_0 on 2020-10-19)

Is it possible to tell kubernetes, that when performing a deployment of multiple pods that it should start only one at a time and only create the next pod if the previous has completely started up?

It would be useful in our usecase:
Our application automatically migrates/upgrades the database when starting up. But when there are multiple pods starting up at the same time, it could happen that multiple pods try to upgrade the database at the same time which could corrupt the database.

But if kubernetes would wait with starting up the second pod until the first pod has fully started up, it would mean that the database has been correctly upgraded by then.

If kubernetes does not have such functionality, how would you handle such a case?

**Tags:** kubernetes


---

## 3 answers

### Answer by username_1 on 2020-10-20. Score: 5

Use a combination of Readiness Probes and a proper deployment strategy.

Configure your Deployment spec like so:
spec:
  replicas: 4    # or as many as you need to have
  strategy:
    rollingUpdate:
  maxUnavailable: 0
  maxSurge: 1

maxUnavailable = 0 means that there should always be a number of pods available equal to the replicas count. maxSurge = 1 means that kubernetes will create the new pods one at a time, and destroy the old ones one-at-a-time as well.
Implement a readinessProbe which should return a successful response when the database migration has completed. You'd have to write the logic for that yourself, but if you do it right, kubernetes will create a pod with the new Deployment and wait for it to complete and only after that, evict 1 of the old ones.

PS: It's worth noting that this approach will cause your node to temporarily contain more pods than your replicas config implies, namely replicas + 1 for a short period of time while deploying. You need to make sure that your node can handle the little extra load untill the rollout is complete.


---

### Answer by username_2 on 2020-10-19. Score: 2

Here you could create a lock table inside your database, then the first pod would take the lock and then run the update. Other pods startup scripts would wait for the lock to be released before starting the application. A simpler solution is to run a pod inside a job for upgrading the database before launching the application.


---

### Answer by username_3 on 2024-11-28. Score: 0

I think you can create init container
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      initContainers:
      - name: db-migration
        image: my-db-migration-image:latest
        command: ["sh", "-c", "run-migration-script.sh"]
        env:
        - name: DATABASE_URL
          value: "your-database-url"
      containers:
      - name: my-app-container
        image: my-app-image:latest
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5


---

