In-depth understanding of Deployments in Kubernetes (Part 2)

In my previous post, I highlighted some key features of Deployment, but if you haven’t seen it yet you can check it out here.

In-depth understanding of Deployments in Kubernetes

Topics:

1. Pausing and Resuming Deployments
2. Proportional scaling
3. Rolling back to the previous version
4. Clean up Policy
5. Canary Deployments

4. Clean up Policy

Previously, we have learned how to roll back to an old version in case of an issue with a current deployment. Behind the scenes, Kubernetes stored numbers of old ReplicaSet so that you can switch to any Replicaset anytime.

By default, every Deployment is set to 10 for reserving the old ReplicaSet, and you can of course can limit this base on your own desired number by specifying .spec.revisionHistoryLimit. The rest will be deleted automatically by a garbage collector.

For example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  labels:
    app: test-app
    tier: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        tier: backend
    spec:
      containers:
        - name: node-app
          image: 10.80.80.148:5000/node-app:0.0.14
          ports:
            - containerPort: 3000
      4. Clean up Policy: 8

5. Canary Deployment

The canary deployment also known as Canary release is a way that you can release a new version of an app along with the stable version. The purpose of this is to help you test new features with a small segment of users.

The term canary deployment itself also comes from an old coal mining technique, where Canaries are more sensitive to airborne toxins than humans, so miners always use them as a detector to prevent danger from going into the mine. This approach has saved multiple of human lives.

You can easily do this in Kubernetes by just creating multiple Deployments and making use of Selector.

For example, we have 2 different Deployments one for the stable version and another one for the new version.

First Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  labels:
    app: test-app
    tier: backend
    track: stable
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        tier: backend
    spec:
      containers:
        - name: node-app
          image: 10.80.80.148:5000/node-app:0.0.14
          ports:
            - containerPort: 3000
      revisionHistoryLimit: 8

Second Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  labels:
    app: test-app
    tier: backend
    track: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        tier: backend
    spec:
      containers:
        - name: node-app
          image: 10.80.80.148:5000/node-app:0.0.15
          ports:
            - containerPort: 3000
      revisionHistoryLimit: 8

Now, we should be able to create a Service that can pair with both Deployments by using Selector.

apiVersion: v1
kind: Service
metadata:
  name: test-app-svc
  labels:
    app: test-app
spec:
  type: NodePort
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
      nodePort: 32222
  selector:
    app: test-app
    tier: backend

By doing so, you have the ratio of Deployment 3:1 and you can continuously observe your new version release until you feel confident enough to completely take over the current one.

Last but not least, I hope this article can help you improve your knowledge of Deployment and also efficiency at your workplace. Please give me a clap if you feel this helpful and also follow me for future posts. Thanks for reading.