Uncategorised

kubernetes deployment strategy explained with example

July 8, 2021 comments off

Fearture of Kubernetes Deployment

  • Replication
  • Controller
  • Versioning
  • Rollout
  • Rollback

Note:
ReplicaSets = Replication+Controller in the Deployment

$ kubectl explain deploy.spec.strategy.type
KIND: Deployment
VERSION: apps/v1

FIELD: type

DESCRIPTION:
Type of deployment. Can be “Recreate” or “RollingUpdate”. Default is
RollingUpdate.

Kubernetes Deployement Strategy

Type of deployment

  • Recreate
  • RollingUpdate

.spec.strategy specifies the strategy used to replace old Pods by new ones. .spec.strategy.type can be “Recreate” or “RollingUpdate”. “RollingUpdate” is the default value

Recreate Deployment

All existing Pods are killed before new ones are created when .spec.strategy.type==Recreate.

This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an “at most” guarantee for your Pods, you should consider using a StatefulSet.

Rolling Update Deployment

The advantage of the rolling update strategy is that the update is applied Pod-by-Pod so the greater system can remain active.

There is a minor performance reduction during this update process because the system is consistently one active Pod short of the desired number of Pods. This is often much preferred to a full system deactivation.

The rolling update strategy is used as the default update strategy but isn’t suited for all situations.

The Deployment updates Pods in a rolling update fashion when .spec.strategy.type==RollingUpdate. You can specify maxUnavailable and maxSurge to control the rolling update process.

   maxSurge     <string>
     The maximum number of pods that can be scheduled above the desired number
     of pods. Value can be an absolute number (ex: 5) or a percentage of desired
     pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number
     is calculated from percentage by rounding up. Defaults to 25%. Example:
     when this is set to 30%, the new ReplicaSet can be scaled up immediately
     when the rolling update starts, such that the total number of old and new
     pods do not exceed 130% of desired pods. Once old pods have been killed,
     new ReplicaSet can be scaled up further, ensuring that total number of pods
     running at any time during the update is at most 130% of desired pods.

   maxUnavailable       <string>
     The maximum number of pods that can be unavailable during the update. Value
     can be an absolute number (ex: 5) or a percentage of desired pods (ex:
     10%). Absolute number is calculated from percentage by rounding down. This
     can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set
     to 30%, the old ReplicaSet can be scaled down to 70% of desired pods
     immediately when the rolling update starts. Once new pods are ready, old
     ReplicaSet can be scaled down further, followed by scaling up the new
     ReplicaSet, ensuring that the total number of pods available at all times
     during the update is at least 70% of desired pods.

kubernetes deployment strategy example: Recreate

apiVersion: apps/v1  
kind: Deployment
metadata:
  name: hello-deploy
spec:
  replicas: 10
  selector:
    matchLabels:
      app: hello-world
  minReadySeconds: 10
  strategy:
    type: Recreate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-Pod
        image: scmgalaxy/nginx-devopsschoolv1
        ports:
        - containerPort: 80

kubernetes deployment strategy example: Rollingupdate

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  replicas: 3
  strategy:
    rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: helloworld
        track: stable
    spec:
      containers:
      - name: helloworld
        image: scmgalaxy/nginx-devopsschoolv1
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 50m
          limits:
            cpu: 100m
Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)