Deployments

A deployment is an object in Kubernetes that helps you to manage a group of identical pods.

Without a deployment, you’d got to produce, update, and delete a bunch of pods manually.

With a deployment, we tend to declare one object in a very YAML file.

Using Kubernetes deployment we can autoscale the applications very easily.

Deployment

Deployment Strategies

When deploying your applications to a K8s cluster, your chosen deployment strategy will determine how those applications are updated to a newer version from an older one. Some strategies will involve downtime.

• Recreate

• Rolling

• Blue/Green

• Canary

1. Recrete

Whenever you apply the recreate strategy, all the existing pods from the previous deployments, are terminated, and replaced with a new version.

The engineers are required to shut down the application entirely, deploy the new version, and start the entire system.

This deployment strategy is better when the engineers want to push a major update of the application instead of a minor or a patch update.

The Recreate deployment strategy is suitable for environments where customers or users do not mind short but announced downtimes.

spec:
  replicas: 10
  strategy:
    type: Recreate

1. Rolling

The rolling update is the default deployment strategy in Kubernetes that update the pods one by one without causing cluster downtime.

In the running update deployment strategy, the Kubernetes deployments update all running pods of the application to a new version one by one.

Engineers can safely transition from one version of the application to another without production errors.

• MaxSurge specifies the maximum number of pods the Deployment is allowed to create at one time.

• MaxUnavailable specifies the maximum number of pods that are allowed to be unavailable during the rollout.

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 1

1. Blue/Green

“Green” refers to the new version of the software that is deployed alongside the old version called the “Blue” version.

While the “Blue” version is running, engineers deploy the “green” version in another deployment and run basic tests to ensure that the pods within the deployments are stable, then using services, you switch to the newer version of the application.

Bule/Green

kind: Service
metadata:
 name: web-app-01
 labels:
   app: web-app
selector:
   app: web-app
   version: v1.0.0

kind: Service
metadata:
 name: web-app-02
 labels:
   app: web-app
selector:
   app: web-app
   version: v2.0.0

1. Canary

A newer version of the application is deployed to a small subset of people in the live Kubernetes cluster.

A small subset of live users will be connected to the application while the rest will still be using the previous version.

The main aim of deploying to the small subset of users is for early error detection and potential problems that are present in the new code.

The main advantage of the canary deployment is that engineers can easily detect application issues very early with a small subset of users.

Canary

Deployment Sample File

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: web
spec:
  selector:
    matchLabels:
      app: web
  replicas: 5
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
       —name: nginx
          image: nginx
          ports:
           —containerPort: 80

• apiVersion represents the version of the Kubernetes API used to create this object

• Kind represents the type of Kubernetes objects to be created while using the YAML file

• The metadata with a spec section to define the replicas and configurations related to the deployment

• The replicas define the number of pods

• The selector in which the controller will select the targeted pods.

• The template section contains the actual template for the pod

• The containers section defines the container details