What Deployment is about
- How to deploy an application in a production environment.
- When a newer versions of application builds are available, to upgrade Docker instances seamlessly
- Not upgrading all application at once, instead one after the other (rolling updates)
- If one of the updates go not successful, we can roll back to before the upgrade
- When making multiple changes during upgrade such as updating Web Server versions or scaling environment and resources,
we wouldn’t want to apply each change immediately after the command, we’d like to apply a pause to the environment,
and make changes and resumes so all the changes are rolled out together.
- Kubernetes deployments provide the capability to upgrade instances seamlessly using rolling updates, undo changes and pause and resume changes as required.
Definition of Kubernetes Definition
- We can create a deployment definition yaml file
# deployment-definition.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
replicas: 3
selector:
matchLabels:
type: front-end
Commands
to create a new deployment
kubectl create -f deployment-definition.yaml
# OR
kubectl create deployment <name> --image=<image_name> --replicas=<number>
# Use scale
kubectl scale deployment <name> --replicas=4
# to view the yaml configuration without running the command
kubectl create deployment <name> --image=<image_name> --replace=<number> --dry-run=client -o yaml
# Save yaml definition file
kubectl create deployment <name> --image=<image_name> --dry-run=client -o yaml > deployment-file.yaml
# OR
# record option tells Kubernetes to record the cause of the change.
kubectl create -f deployment-definition.yaml --record
kubectl edit deployment myapp-deployment --record
to get all the deployments
kubectl get deployments
# OR
kubectl get deploy
to get all Kubernetes objects created
kubectl describe deployment <deployment_name>
to edit the deployment
# When we edit deployment, the deployment will automatically delete and
# create a new pod with the new changes. Therefore, we can edit any field
# or property of the pod template.
kubectl edit deployment <deployment_name>
Updates and Rollback
Rollout and Versioning
- When creating a deployment, it triggers a rollout and a new rollout creates a new deployment (revision 1).
- WHen the deployment is upgraded later, a new roll out is triggered and a new deployment revision is created (revision 2).
- Revisioning is helpful so that we can keep track of changes and roll back to a previous revision later if necessary.
Commands
to rollout
kubectl rollout status deployment/<deployment_name>
to view history of rollout
kubectl rollout history deployment/<deployment_name>
to do upgrade the deployment
kubectl apply -f deployment-definition.yaml
# a new rollout is triggered and a new revision of the deployment is created.
to update the image of your application
kubectl set image deployment/<deployment_name> <image_name>=<new_image>
# ex
kubectl set image deployment/myapp-deployment nginx-container=nginx:1.9.1
# or
# This does not change the already-existing deployment-definition file. We need to be careful for it.
kubectl set image deployment myapp-deployment nginx=nginx:1.18-perl
to undo the change
kubectl rollout undo deployment/<deployment_name>
# roll back to the previous revision
# It'll destroy pods in the new replica set and bring up the pods in the older replica set.
Deployment Strategies
- Recreate Strategy: Destroy all existing application instances and create newer versions of instances
- Disadvantage: there is a downtime between when all applications are destroyed and when newer instances are up.
- Rolling Update Stragety (default): Destroy the olde version and bring up a newer version one by one.
- Advantage: application never goes down and upgrade is seamless.
Deployment process
- When a new deployment is created, it creates a replica set automatically first.
- Then, the replica set creates the number of pods required to meet the number of replicas.
- When we upgrade a deployment, Kubernetes creates a new replica set.
- Then it starts creating containers there, while it destroys the pods in the old replica set.
Notes
- Deployment automatically creates a replica set (we can check with
kubectl get replicaset) - Similarly, deployment automatically creates pods as well
Referenes