<p>I've set up 2 replicas of a deployment. </p>

<p>when I use </p>

<pre><code>strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
</code></pre>

<p>It only updates 1 pod when I update it via set Image. The second pod doesnot get updated with new code. This means 1 have 2 pods running different images. </p>

<p>When I set maxSurge 25% and maxUnavailable 25%, the pods don't get replaced at all.</p>

<p>Here's the complete yaml </p>

<pre><code>apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "89"
  creationTimestamp: 2018-11-26T09:40:48Z
  generation: 94
  labels:
    io.kompose.service: servicing
  name: servicing
  namespace: default
  resourceVersion: "6858872"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/servicing
  uid: 5adb98c8-f15f-11e8-8752-42010a800188
spec:
  replicas: 2
  selector:
    matchLabels:
      io.kompose.service: servicing
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        io.kompose.service: servicing
    spec:
      containers:
      - env:
        - name: JWT_KEY
          value: ABCD
        - name: PORT
          value: "3001"
        image: gcr.io/something/something
        imagePullPolicy: Always
        name: servicing-container
        ports:
        - containerPort: 3001
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 3001
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          requests:
            cpu: 25m
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2018-12-13T11:55:00Z
    lastUpdateTime: 2018-12-13T11:55:00Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  observedGeneration: 94
  readyReplicas: 2
  replicas: 2
  updatedReplicas: 2
</code></pre>

Alamgir Munir Qazi
<p>You have setup <code>initialDelaySeconds</code> to 5, <code>periodSeconds</code> to 5 and <code>failureThreshold</code> to 3, it means that kubernetes will wait initial 5 seconds to do first probe to your application is ready or not and then periodically probe your app every 5 seconds if it is ready or not and will do it 3 times. So your application will be checked at 10 second, 15 second and 20 second and if pod doesn't come up in that time, it bails out without upgrading.</p>

<p>You might need to increase this <code>failureThreshold</code> so that your app does have enough time to come up.</p>

<p>Also, I would suggest you to make <code>maxUnavailable</code> to 0 so that pod will be deleted only when the new pod comes up in its replacement.</p>

<p>Check my answer here for better understanding:</p>

<p><a href="https://stackoverflow.com/questions/53668964/kubernetes-0-downtime-using-readiness-probe-and-rollback-strategy-not-working/53669069#53669069">Kubernetes 0 Downtime using Readiness Probe and RollBack strategy not working</a></p>
