- It helps us to manage set of identical pods without creating/updating/deleting pods manually.
- It makes desired number of identical pods always stay up and running automatically without user intervention.
- It is a high-level resource, the actual pods are created and managed by the ReplicaSets, not by the Deployment directly.
- ReplicaSet constantly monitors the list of running pods and makes sure the actual number of pods are always matching the desired number of pods. It there are only few pods are running, it creates new replicas from a pod template. If there are many pods are running than desired number, it removes the excess replicas.
- Deployment YAML file contains both desired replica count and Pod template in it. Therefore, it will not depend on external Pod YAML file to create new Pod replicas.
- If one cluster node fails, Deployment will create desired number of replicas on another node automatically without manual intervention.
Deployment Strategies
1. RollingUpdate: This is the default strategy for the Deployment. It removes old pods one by one, while adding new ones at the same time. This strategy helps us to serve the application without downtime.
maxSurge and maxUnavailable are two properties used to control the rate of rollout.
maxSurge: It determines how many maximum number of Pods can be created on top of the desired number of Pods. The number can be declared as absolute number (i.e. 1) or percentage (i.e. 20%). The default value is 25%
maxUnavailable: It determines maximum number of Pods that can be unavailable during deployment process. The number can be declared as absolute number (i.e. 1) or percentage (i.e. 20%). The default value is 25%
Note: Use this strategy only when your application can handle running both the old and new version at the same time.
2. Recreate: This strategy deletes all the old pods at once before creating new ones. This requires short period of complete application downtime.
Note: Use this strategy when your application does not support running multiple versions in parallel and requires the old version to be stopped completely before the new one is started.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
// Create a Deployment based on the YAML file
$ kubectl apply -f ./nginx-deployment.yaml
deployment.apps/nginx-deployment created
// Display information about all deployments
$ kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/3 2 2 64s
NAME: name of the deployment
READY: How many Pods are available to access
UP-TO-DATE: How many Pods are updated as per latest Pod template
AVAILABLE: How many Pods are available to access
AGE: Since how long application has been running
// Display ReplicaSet created by the Deployment
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-6b474476c4 3 3 3 52m
NAME: name of the ReplicaSet i.e. [DEPLOYMENT NAME]-[RANDOM STRING]
DESIRED: Display desired number of Pods which specified in the deployment.yaml file
CURRENT: how many Pods are currently running
READY: How many Pods are available to access
AGE: Since how long application has been running
// Display information about the Pods
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-6b474476c4-b6j4j 1/1 Running 0 3h31m
nginx-deployment-6b474476c4-dk6wm 1/1 Running 0 3h31m
nginx-deployment-6b474476c4-xfdd9 1/1 Running 0 3h31m
// Display complete information about the Deployment
$ kubectl describe deployment nginx-deployment
// Filter Pods using labels
$ kubectl get pods -l app=nginx
// display deployment rollout history
$ kubectl rollout history deployment nginx-deployment
// undo deployment to previous revision
$ kubectl rollout undo deployment nginx-deployment
// undo deployment to specific revision
$ kubectl rollout undo deployment nginx-deployment --to-revision=2
// Delete the deployment
$ kubectl delete deployment nginx-deployment
Kubernetes for Developers Journey.
- Kubernetes for Developers #25: PersistentVolume and PersistentVolumeClaim in-detail
- Kubernetes for Developers #24: Kubernetes Volume hostPath in-detail
- Kubernetes for Developers #23: Kubernetes Volume emptyDir in-detail
- Kubernetes for Developers #22: Access to Multiple Clusters or Namespaces using kubectl and kubeconfig
- Kubernetes for Developers #21: Kubernetes Namespace in-detail
- Kubernetes for Developers #20: Create Automated Tasks using Jobs and CronJobs
- Kubernetes for Developers #19: Manage app credentials using Kubernetes Secrets
- Kubernetes for Developers #18: Manage app settings using Kubernetes ConfigMap
- Kubernetes for Developers #17: Expose service using Kubernetes Ingress
- Kubernetes for Developers #16: Kubernetes Service Types - ClusterIP, NodePort, LoadBalancer and ExternalName
- Kubernetes for Developers #15: Kubernetes Service YAML manifest in-detail
- Kubernetes for Developers #14: Kubernetes Deployment YAML manifest in-detail
- Kubernetes for Developers #13: Effective way of using K8 Readiness Probe
- Kubernetes for Developers #12: Effective way of using K8 Liveness Probe
- Kubernetes for Developers #11: Pod Organization using Labels
- Kubernetes for Developers #10: Kubernetes Pod YAML manifest in-detail
- Kubernetes for Developers #9: Kubernetes Pod Lifecycle
- Kubernetes for Developers #8: Kubernetes Object Name, Labels, Selectors and Namespace
- Kubernetes for Developers #7: Imperative vs. Declarative Kubernetes Objects
- Kubernetes for Developers #6: Kubernetes Objects
- Kubernetes for Developers #5: Kubernetes Web UI Dashboard
- Kubernetes for Developers #4: Enable kubectl bash autocompletion
- Kubernetes for Developers #3: kubectl CLI
- Kubernetes for Developers #2: Kubernetes for Local Development
- Kubernetes for Developers #1: Kubernetes Architecture and Features
Happy Coding :)
No comments:
Post a Comment