In the context of Kubernetes, a deployment is a resource object that represents a declarative update to applications. Deployments are a crucial concept in Kubernetes for managing and updating applications in a containerized environment. Here are some use cases for deployments:
Rolling Updates and Rollbacks:
- Use Case: When you want to update the application to a new version or make changes to the configuration without causing downtime.
- How Deployments Help: Deployments manage the rollout and rollback of updates in a controlled manner, ensuring zero-downtime updates by incrementally updating instances.
Scaling Applications:
- Use Case: When you need to scale your application horizontally to handle increased load.
- How Deployments Help: Deployments allow you to easily scale the number of replicas (instances) of your application up or down to accommodate changes in demand.
Fault Tolerance:
- Use Case: Ensuring high availability of your application by maintaining a specified number of replicas.
- How Deployments Help: Deployments can be configured to maintain a specific number of replicas at all times. If a pod fails, the deployment controller automatically replaces it with a new one.
Rollback to Stable State:
- Use Case: When a new version of the application introduces critical bugs or issues, and you need to quickly roll back to a stable state.
- How Deployments Help: Deployments keep track of the desired state, and rolling back is as simple as instructing the deployment to revert to a previous version.
Easy Configuration Updates:
- Use Case: When you want to update configuration parameters or environment variables for your application.
- How Deployments Help: You can update the deployment configuration, and Kubernetes will automatically roll out the changes to all running instances.
Resource Scaling and Load Balancing:
- Use Case: To automatically adjust the number of replicas based on resource utilization or traffic patterns.
- How Deployments Help: Deployments can be configured with Horizontal Pod Autoscalers (HPA) to automatically scale the number of replicas based on specified metrics.
Resource Cleanup:
- Use Case: When you need to delete and clean up resources associated with a specific application.
- How Deployments Help: Deleting a deployment will automatically delete associated pods, services, and other resources, simplifying cleanup.
In summary, deployments in Kubernetes provide a powerful and declarative way to manage the lifecycle of applications, ensuring reliability, scalability, and ease of maintenance in containerized environments
====================================================================
kubectl create deployment <deployment-name> --image=<container-image>
kubectl expose deployment <deployment-name> --type=LoadBalancer --port=<external-port>
kubectl expose deployment <deployment-name> --type=NodePort --port=<external-port>
kubectl create deployment nginxdep --image=nginx:latest --replicas 3 --dry-run -o yaml
#Expose port as a service
kubectl expose deployment deploymentname --port=8000 --target-port=80 --type=NodePort
#scale deployment
kubectl scale deployment --replicas=6 deploymentname
#Update Deployment (Rolling Update):
kubectl set image deployment <deployment-name> container-name=<new-image>
#Rollback Deployment:
kubectl rollout undo deployment <deployment-name>
#Check Deployment Status:
kubectl rollout status deployment <deployment-name>
#Rollout history if want to see the changes of you should enable record
kubectl rollout history deployment deployment-name
Note: Always best practice make the changes in Yaml file
====================================================================
Declarative
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginxdep
name: nginxdep
spec:
replicas: 3
selector:
matchLabels:
app: nginxdep
template:
metadata:
labels:
app: nginxdep
spec:
containers:
- image: nginx:latest
name: nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
maxSurge: Specifies the maximum number of pods that can be created over the desired number of replicas during the rolling update. In this case, it is set to 1, meaning that only one additional pod beyond the desired replica count can be created at a time.
"whenever we update the image lets say we have 3 replicas now maxsurge count after creating 1 new extra pod then only it will overide or delete the desired replicas counts pod i.e at any cost it will always maitain the desired count while updating the deployment"
we can track the update changes by using below command
kubectl rollout status deployment <deployment-name>
The kubectl rollout pause command in Kubernetes is used to pause the rolling update of a deployment. Pausing a rollout is useful in situations where you want to temporarily halt the deployment process, perhaps to investigate an issue or to perform some manual interventions before allowing the update to proceed.
kubectl rollout pause deployment <deployment-name>
maxUnavailable: Specifies the maximum number of pods that can be unavailable (i.e., old pods being terminated) during the rolling update. In this case, it is set to 1, meaning that at most one pod can be unavailable at a time.
"It means while updating it will delete or remove one pod from desired count of replicas lets say in our scenario its 3-2 i.e 2 will be available
=================================================================
Deployment types;
Blue/green
canary
rolling update
2. Recreate:
Here rollout time to new update version instead of creating the new replica set it will recreate the pods inside the existing replica set.
By using recreate will get more speed instated of rolling deployment.
3.canary deployment & blue green deployment & red & green deployment
Industry mostly this strategy only people are using it.
When traffic will come from internet we are passing that traffic info green environment we can say production in blue testing will happen .
What ever rollout updates & developments we can do in blue environment.
When dev & testing done that time will redirect traffic from ingress controller to blue environment in green environment we can update that things means that in production.
Means production will shift will change depends on requirement
=================================================================
If you want to revert your deployment changes then
#Rollback Deployment:
kubectl rollout undo deployment <deployment-name>
It will delete the new deployment which will create and will revert to the old one
#Update Deployment (Rolling Update):
kubectl set image deployment <deployment-name> container-name=<new-image> --record=true
If you run with above record option now you can see those changes in your history.
kubectl rollout history deployment deployment-name
---------------------------------Deployment max surge---------------------------
The maxSurge and maxUnavailable settings are commonly used in Kubernetes during rolling updates to control the rate of deployment and the number of pods that can be taken down at once. These settings are part of the RollingUpdate strategy in a Kubernetes Deployment or StatefulSet.
maxSurge: 1: This setting controls the maximum number of pods that can be created above the desired number of replicas during the update process. In this case, it allows one additional pod to be created at a time.
maxUnavailable: 1: This setting controls the maximum number of pods that can be unavailable (removed from service) during the update process. In this case, it allows one pod to be unavailable at a time.
max surge will create extra pods depends on count or percentage in mentione value maxSurge: 50%
i.e relicas set in depoyment is 2 so for 50% is 1 pod that is it will add one more extra pod updating deployment when you modify image in deployment
strategy:
type: RollingUpdate
rollingUpdate:
#maxSurge: 1 we can use as integer type and with percentage as well
maxSurge: 50%
maxUnavailable: 0
Total file:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
#maxSurge: 1 we can use as integer type and with percentage as well
maxSurge: 50%
maxUnavailable: 0
If you see by default 2 pods are creating as mentioned in
0 Comments