Certified Kubernetes Administrator Study Guide – Application Lifecycle Management – Understand Deployments and how to perform rolling updates and rollbacks

• https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• Deployments are a construct that contains one or more containers, pods, services, daemonsets etc
• They are the default controller when a container is deployed via kubectl run command
• Creating a deployment automatically creates a replicaset which contains a pod which in turn contains one or more containers
• Created using yaml spec with the kind value of Deployment

kubectl apply -f <manifest file path>

• They have metadata and spec sections just like other Kubernetes objects do but contain two spec sections one for the replicaset and one for the pod

• Check what deployments exist using

kubectl get deployments

• To see the details of the deployment

kubectl describe deployment <deployment name>

• To generate a yaml file for the deployment use

kubectl get deployments, rs, pods -o yaml

• Deployments can be scaled up/down by increasing/decreasing the number of replicas within the replicaset

• If a deployment has a value of 0 for the number of replicas this results in no containers being deployed but the replicaset and deployment would still be present

• Can also use the command

kubectl scale --replicas=<number of replicas> deployment <deployment name>

• Replicasets contain a number of replicas of each pod that should exist at all times across the Kubernetes cluster

• The ReplicationControllers ensures that the correct number of replicas are running
• The ReplicationControllers also allow rolling updates but these are on the client side and can cause the cluster state to enter unplanned states if connection from the client is interrupted for example. kubectl rolling update is the command to perform client side rolling updates
• Deployments are all server side rolling updates
• If an update is made to the spec of the Deployment a new replicaset is deployed using the new spec. The new replicaset contains pods running based on the new spec. As the new pods come online the deployment informs the original replicaset to start shutting down pods as they are replaced by the new pods.
• When all of the original pods have been terminated the deployment terminates the original replicaset
• Rolling updates are used by default when things like a version value are changed within the deployment spec
• Update strategy is defined within the deployment spec under the strategy section

strategy:
  rollingUpdate: 
  maxSurge: 25% 
  maxUnavailable: 25%
  type: RollingUpdate

• maxSurge is the maximum number of pods to create over and above the desired number during an update and creation of the new replicaset
• maxUnavailable is the minimum number of pods that are available during an
  update
• To view the status of a rollout

kubectl rollout status <deployment name>

• Can rollback update to previous revision using (ideally use the –record=true option when applying the update to log the kubectl command executed to perform the update in the revision history)

kubectl rollout undo deployment <deployment name>

• Can rollback to a specific revision using

kubectl rollout undo deployment <deployment name> --to-revision=<revision number>

• Can view the rollout history for a deployment using

kubectl rollout history deployment <deployment name>

• Can drill into a particular revision using

kubectl rollout history deployment <deployment name> --revision=<revision number>