<p>I'm using the <code>kubectl rollout</code> command to update my deployment. But since my project is a NodeJS Project. The <code>npm run start</code> will take some take(a few seconds before the application is actually running.) But Kubernetes will drop the old pods immediately after the <code>npm run start</code> is executed.</p>
<p>For example,</p>
<pre><code>kubectl logs -f my-app

&gt; my app start
&gt; nest start
</code></pre>
<p>The Kubernetes will drop the old pods now. However, it will take another 10 seconds until</p>
<pre><code>Application is running on: http://[::1]:5274
</code></pre>
<p>which means my service is actually up.</p>
<p>I'd like to know whether there is a way to modify this like waiting some more time before kubernetes drop the old pods.</p>
<p>My docker file:</p>
<pre><code>FROM node:14 AS builder
# Create app directory
WORKDIR /app
# A wildcard is used to ensure both package.json AND package-lock.json are copied
COPY package*.json ./
COPY prisma ./prisma/
COPY protos ./protos/
COPY tsconfig.build.json ./
COPY tsconfig.json ./
# Install app dependencies
RUN npm install
RUN export NODE_OPTIONS=--max_old_space_size=16384
RUN npm run build
COPY . .
# FROM node:14
# COPY --from=builder /app/node_modules ./node_modules
# COPY --from=builder /app/package*.json ./
# COPY --from=builder /app/dist ./dist
# COPY --from=builder /app/protos ./protos
EXPOSE 5273
CMD [&quot;npm&quot;, &quot;run&quot;, &quot;start&quot;]
</code></pre>
<p>Spec for my kubernetes yaml file:</p>
<pre><code>spec:
  replicas: 4
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: image
        imagePullPolicy: Always
        resources:
          limits:
            memory: &quot;8Gi&quot;
            cpu: &quot;10&quot;
          requests:
            memory: &quot;8Gi&quot;
            cpu: &quot;10&quot;
        livenessProbe:
          httpGet:
            path: /api/Health
            port: 5274
          initialDelaySeconds: 180
          periodSeconds: 80
          timeoutSeconds: 20
          failureThreshold: 2
        ports:
        - containerPort: 5274
        - containerPort: 5900
</code></pre>

Zichzheng
<p>Use a startup probe on your container. <a href="https://docs.openshift.com/container-platform/4.11/applications/application-health.html" rel="nofollow noreferrer">https://docs.openshift.com/container-platform/4.11/applications/application-health.html</a> . Pods don't count as &quot;ready&quot; until all of their containers have passed their startup (and readiness) checks.</p>
<p>And during a deployment the scheduler counts non-ready pods as &quot;unavailable&quot; for things like the &quot;maxUnavailable&quot; setting of the deployment. Thus the scheduler won't keep shutting down working pods until new pods are ready for traffic. (<a href="https://docs.openshift.com/container-platform/4.11/applications/deployments/deployment-strategies.html" rel="nofollow noreferrer">https://docs.openshift.com/container-platform/4.11/applications/deployments/deployment-strategies.html</a>)</p>
<p>As an additional benefit, services won't route traffic to non-ready pods, so they won't receive any traffic until the containers have passed their startup probes.</p>
