A Deployment provides declarative updates for Pods and ReplicaSets.
Deployments add additional capabilities to Pods: rolling updates, rollbacks, ...
Deployments leverage the ReplicaSet objects. They are automatically created when Deployments are created.
ReplicaSet objects provide additional features to Deployments: self-healing and scaling capabilities.
-
Rolling updates (zero-downtime):
When you update Deployment and you post the changes to the API server, Kubernetes creates a new ReplicSet for the Pods (with all the new changes).
While the Deployment is applied, you will notice that two ReplicSets exist for the Deployment:
One with the original changes and a second that reflect the new changes.
For each Pod that is successfully created for the new ReplicaSet, a corresponding one from the old ReplicaSet will be terminated.
If the update is successful, the old ReplicaSet will have no Pod.
The old ReplicaSet itself won't be deleted.
Deployments provides settings to control the sequence of time by which Pods will be created.
A wait time can be added between Pods creation/termincation.
-
Rollbacks:
If after you update a Deployment, you decide to rollback the changes of the new Deployment,
the old ReplicaSet will be there and you can perform "easily" the rollback.
-
Self healing:
Self healing is the ability to re-create a Pod if it fails.
-
Scaling:
Scaling is the ability to add new Pods or delete existing Pods.
Scaling is used to adjust the number of the Pods when the load on the system increases or decreases.
To create/deploy a Deployment, you need to create a manifest YAML file.
The manifest file describe the Deployment and its components (name, Pods, ...).
Here's a sample file ("hello-nginx-deployment.yaml") that provides a declarative configuration of a Deployment:
$ vi hello-nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-nginx
labels: # define labels for the Deployment (can be used to delete the Deployment: kubectl delete deployment -l "app=hello-nginx")
app: hello-nginx
spec:
replicas: 1
selector:
matchLabels: # define labels that Pods should define in order to apply for the Deployment
app: hello-nginx
minReadySeconds: 3
template:
metadata:
labels:
app: hello-nginx
spec:
containers:
- name: hello-nginx
image: nginx:latest
ports:
- containerPort: 80
You can use "
kubectl" (or any rest client tool) to post the manifest file to the API server
If applicable, the API server verifies that the request is authenticated, validates it's authorized, and runs the admission controllers on it.
The API server verifies the manifest file and, if no issues, it writes a record for that manifest in the cluster store (etcd).
The scheduler will then read the record and deploy the Pod of the Deployment to a healthy worker node with enough available resources.
The same behaviour, described above, applies if you use the imperative command ("kubectl create") to create the Deployment.
To apply the deployment:
$ kubectl apply -f hello-nginx-deployment.yaml
deployment.apps/hello-nginx created
The "hello-nginx-deployment.yaml" file defines the following fields:
-
The apiVersion field defines the Kubernetes API group and the Kubernetes API version.
Its value is written as following: <api-group>/<api-version>
For Deployments: apps/v1
-
The kind field defines the type of the Kubernetes object to be created (Deployment).
-
The metadata field defines the Deployment metadata (name, labels, namespace, ...).
-
The spec field defines the Pod information.
-
The spec.replicas field defines the number of instances to be created for the Pod.
-
The spec.selector field defines a list of labels that Pods must have in order for the Deployment to manage them.
-
The spec.minReadySeconds field defines the minimum number of seconds for which a newly created Pod should be ready
without any of its containers crashing, for it to be considered available.
This defaults to 0 (the Pod will be considered available as soon as it is ready).
-
The spec.template field defines the Pod information (metadata, containers, ...).
The
spec.strategy field can be used to define how to perform updates to the Pods managed by the Deployment.
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 2
maxSurge: 2
-
The spec.strategy.type field defines the rolling update strategy:
RollingUpdate: gradually terminating old Pods as soon as the new ones are created.
Recreate: terminating old Pods first, then create the new ones.
Custom: allows you to customize the deployment behavior.
-
The spec.strategy.rollingUpdate.maxUnavailable field defines the number of Pods that can be unavailable during the update, without impacting the desired state (desired number of Pods: replicas).
-
The spec.strategy.rollingUpdate.maxSurge field defines the number of new Pods that can be created during the update, where the total number of Pods is above desired state (desired number of Pods: replicas).
For example, if the desired state of the Pod is 10 instances (
replicas: 10), then:
-
Setting maxUnavailable to 2, means, minimum 8 Pods must be available during the update..
-
Setting maxSurge to 2, means, maximum 12 Pods can be available during the update.
It means, for this case, the rolling update strategy can manage maximum four (the sum of maxUnavailable and maxSurge) Pods at a time
(the update will be creating 0-2 Pods or/and terminating 0-2 Pods).
Note: Managing Deployments using the Manifest Yam file (declarative) is the recommended way,
but in some cases you might want to use the imperative command "kubectl create" to create a Deployment.
$ kubectl create deployment hello-nginx --image=nginx:latest
deployment.apps/hello-nginx created
You can use the "--dry-run" flag to print the YAML file:
$ kubectl create deployment hello-nginx --image=nginx:latest --dry-run=client -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: hello-nginx
name: hello-nginx
spec:
replicas: 1
selector:
matchLabels:
app: hello-nginx
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: hello-nginx
spec:
containers:
- image: nginx:latest
name: nginx
resources: {}
status: {}