Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-10-20T12:19:15.967Z
Answers: 2020-10-20T15:30:42.303Z
Answers: 2020-10-20T15:30:42.303Z
Answers: kalatabe
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-10-19T17:44:54.770Z
Answers: 2020-10-19T17:44:54.770Z
Answers: Fabrice Jammes
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-11-28T10:38:36.497Z
Answers: 2024-11-28T10:38:36.497Z
Answers: Qodirov Shohijahon
Body: <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>
  
Tags: <kubernetes>
Title: Start only one pod at a time in kubernetes
UserDisplayName: Van Coding
ThreadText: # 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](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) and a proper deployment strategy.
  
  1. 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.
  2. 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
  
  ```yaml
  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
  
  ```
  
  
  ---
  
  