Deployment Controller (or Deployment Object) in Kubernetes is about providing so called Rolling Deployments, Blue Green Updates. Blue Green Update is first introducing new version of pods and then removing older version. But entire replacement of pods is not the best idea due to utilization overload and consuming resources.

kubectl create deploy/deployment <deployment name> –image <image name from docker hub> – command for creating deployment

A Replica Set is always created along with deployment (by default number of replicas is 1). By default Replica Set is named by the template <deployment name>-<replica set id> and pod(s) is/are named <deployment name>-<replica set id>-<pod id>.

kubectl scale deploy <deployment name> –replicas <number of replicas> – command that scales the number of underlying pods up (or down) to number of replicas (same as with Replica Set/Replica Controller).

The difference between Deployment Controller and Replica Set is that Deployment Controller defines Deployment Strategy (Rolling Update by default, one by one sequentially) when changing pods versions. See yaml script below :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubeserve
spec:
  replicas: 5
  minReadySeconds: 20 # wait for 10 sec before pod is ready going to next
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # take down 1 pod at a time
      maxSurge: 1        # bring one at a time
  selector:
    matchLabels:
      app: kubeserve
  template:
    metadata:
      name: kubeserve
      labels:
        app: kubeserve
    spec:
      containers:
      - image: leaddevops/kubeserve:v1
        name: app

---
kind: Service
apiVersion: v1
metadata:
   name: kubeserve-svc
spec:
  type: NodePort
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector: 
    app: kubeserve

strategy section in the first yaml (before —) defines deployment strategy.

kubectl rollout status deploy <deployment name> – command that shows whether the given deployment is completed or not

kubectl rollout history deploy <deployment name> – command that shows how many versions were deployed so far

kubectl set image deploy <deployment name> <container name>=<image name from docker hub> –record=true/false – command that replaces image for containers in the given deployment. When executing the command the Deployment works according to strategy settings. –record parameter is optional, if it is set to true, then command used for making changes in the Deployment is shown in CHANGE-CAUSE column in the rollout history

kubectl rollout undo deploy <deployment name> –to-revision=<revision number> – command that rollbacks to defined revision version of Deployment. If –to-revision parameter is omitted, then there will be rollback to previous version

Changes in Deployment don’t update Replica Sets, but create new Replica Sets.

If one of subsequent revisions is equal to one of the previous revisions, previous revision gets pulled out from the history.