Skip to content

Recreate

This is Part 2 of a multi-part, self-paced quick start exercise.

What Will You Do

In part 2, you will test how the "Recreate" deployment pattern works. A deployment defined with a strategy of type "Recreate" will terminate all the running instances then recreate them with the newer version.

The recreate strategy ensures that the old and new pods do not run concurrently. This can be beneficial when synchronizing changes to a backend datastore that does not support access from two different client versions.

Recreate Strategy

Advantages

  • Application state is entirely renewed
  • Does not require additional resources. Well suited for pre-prod environments with limited resources
  • Suited for applications that do not support having new and old versions running at the same time i.e. application does not support multiple versions.
  • Have a ReadWriteOnce volume mounted to your Pod and you cannot share it with a Replica.
  • Want to stop processing old data and need to run some prerequisites before you start up your new application.

Disadvantages

  • Downtime depends on both shutdown and startup time of the application

Estimated Time

Estimated time burden for this part is 5 minutes.

Background

Assuming you completed Part-1, you should have a GitOps pipeline operational that will keep the manifests in your Git repos in sync with your cluster. The deployment backing your current workload should look something like the following.

Notice that the "strategy" is set to "Type:Recreate". This means, during an update, all running instances will first be terminated and then recreated with the newer version.

apiVersion: v1
kind: Service 
metadata:
  name: echo
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 5678
    protocol: TCP
  selector:
    app: echo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-blue
spec:
  selector:
    matchLabels:
      app: echo
  strategy:
    type: Recreate
  replicas: 2
  template:
    metadata:
      labels:
        app: echo
        version: "1.0"
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo
        args:
        - "-text=Blue"
        ports:
        - containerPort: 5678

Step 1: Setup

  • Open Terminal
  • Copy the following command, enter the External-IP for your Load Balancer and execute it. 
while true; do sleep 1; curl http://<External-IP from above>;done

This will execute cURL against the configured IP every second. You should see something like the following. 

Blue
Blue
Blue....

Step 2: Update Version

  • Navigate to your Git repo -> echo.yaml file and Edit
  • Update the text for "args" from "-text=Blue" to "-text=Blue v2"
  • Commit the changes to your Git repository

The update will trigger the Gitops pipeline and it will automatically update the workload on the cluster.

In your terminal from Step 1, you will notice that cURL will fail to connect to your application for a few seconds. This happens because with the "Recreate" deployment strategy, the existing pods are terminated "first" before the new pods are created. Once these pods are ready, cURL will be able to reconnect to the pods and the new message "Blue v2" will be displayed. 

Blue
Blue
Blue
curl: (7) Failed to connect to 40.118.212.71 port 80: Connection refused
Blue v2
Blue v2

Recap

In this part, you tested and experienced how the "Recreate" deployment pattern/strategy works.