What are Deployments in Kubernetes? & it's Use Cases

Deployments in Kubernetes

A deployment is a high-level resource object in the Kubernetes ecosystem that enables users to declaratively create and control the lifespan of a group of identical Pods. Although Pods are the smallest deployable units in a cluster, they are not self-healing and are by nature transient. By offering a strong architecture for self-healing, scalability, and automated rollouts of applications usually those that don’t store state deployments address this issue. The Deployment controller attempts to alter the current state to match the desired state at a predetermined rate by expressing the desired state in a Deployment manifest.

Use Cases

The following are examples of common deployment use cases:

To implement a ReplicaSet, create a Deployment. Pods are automatically created by the ReplicaSet. To determine rollout success, check its status.
Change the Deployment’s PodTemplateSpec to declare the Pods’ new state. The Deployment generates a new ReplicaSet and scales down the old one to replace Pods at a regulated rate. Additions to ReplicaSets change the deployment revision.
If the deployment’s current state is unstable, roll back to an earlier deployment revision. The deployment revision is updated with each rollback.
Increase the deployment’s scale to accommodate greater load.
A deployment’s rollout can be paused to make certain fixes to its PodTemplateSpec, then restarted to begin a fresh rollout.
Use the deployment’s state as a clue that a rollout is stuck.
Get rid of older ReplicaSets that are no longer needed.

You can also read What is Declarative in Kubernetes? & Key Declaratives

Methods for Creating a Deployment

Kubernetes can be deployed using command-line or configuration files. A high-level deployment manager updates Pods and ReplicaSets declaratively to keep your app running.

The Imperative Method:

Launching an app for testing is fastest this way. Use kubectl to direct the cluster. For instance, kubectl create deployment [name] --image=[image] will immediately find a suitable node and schedule an application instance. This method is faster but less transparent for tracking changes.

Create the Deployment Manifest

Start with a YAML or JSON configuration file describing your needs. This manifest typically has four top-level fields:

apiVersion: The Kubernetes API version for deployments is apps/v1.
kind: Specifies the kind of item, which is deployment.
metadata: Includes the deployment name and optional labels.
spec: The most important block, in which the technical requirements are defined.

Key Spec Components

The spec block is where you have to define:

Metadata: This comprises labels and the deployment’s name, which are used to link deployments to other resources like services.
Selector: This parameter specifies how the deployment locates the Pods that it is supposed to oversee. After the deployment is created, the selector in API version apps/v1 is unchangeable.
Template: The Pods’ blueprint. It includes the image to be used and the ports to be opened, together with a specification for the containers.
Replicas: An optional field with a default value of 1 for pod quantity. The control plane sets this value based on CPU use using an HPA.

Example Manifest (nginx-deployment.yaml):

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
        ports:
        - containerPort: 80

Submit the Manifest to the API Server

Use kubectl to send your file to the Kubernetes API server.

The Preferred Method: Use kubectl apply -f .yaml for the preferred method. This is the normal declarative command since it allows recurrent state reconciliation. It updates the Deployment with file modifications if it already exists.
The Alternative Method: Try kubectl create -f .yaml instead. If the resource exists, this operation fails. Build a resource from scratch instead.

You can also read How to Install Kubeadm in Kubernetes Step by Step Guide

Verification and Monitoring

The Deployment controller starts the reconciliation process to spin up the requested Pods after submitting the manifest and noting the new “record of intent” in the cluster store (etcd). Status can be confirmed using these commands:

kubectl get deployments (or kubectl get deploy): At a high level, “kubectl get deployments” (also known as “kubectl get deploy“) shows the deployment’s state, including current and ready replicas.
kubectl get pods: Get pods lists all deployment pods.
kubectl describe deployment <name>: Kubectl describe deployment provides a detailed multiline explanation of current events, labels, and update method.

Critical Considerations

Resource Availability: Insufficient quota, image pull difficulties, and Pod readiness probe failures can stop a deployment. Rollouts that fail within 600 seconds (progressDeadlineSeconds) are reported as failed.
Labels and Selectors: Your deployment’s labels and selectors must not conflict with StatefulSets or other controllers. Controllers may “fight” over pods due to overlapping selectors, causing unexpected behavior.
Pod-Template-Hash: Each ReplicaSet that the Deployment generates is automatically given a pod-template-hash label by Kubernetes. This guarantees that child ReplicaSets don’t overlap; you should never manually change this label.

You can also read Kubernetes Controller Manager vs Cloud Controller Manager

Updating a Deployment

A Kubernetes deployment’s Pod template (.spec.template) changes trigger an automated rollout, the main means to update it. Template changes (such container pictures or labels) trigger rollouts, but not other activities (like adding replicas).

Methods for Updating

Depending on your workflow, there are many ways to update a deployment:

kubectl set image: Kubectl set image changes container images quickly. Kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 instructs the controller to utilize it.
kubectl edit: To live-edit manifests, open the deployment settings in your default terminal editor with kubectl edit. The update is applied after saving and closing.
kubectl apply: You can use kubectl apply -f [filename] after modifying your local YAML or JSON manifest file according to declarative management best practices. This method is preferred for production because it provides a precise version control history.
kubectl patch: The kubectl patch lets you alter API objects by specifying fields.

Update Strategies

The .spec.strategy.type field controls how Kubernetes replaces old Pods with new ones:

RollingUpdate (Default): This strategy ensures high availability by gradually replacing old Pods. It limits Pod availability and generation to a set quantity.
Recreate: This tactic destroys every Pod that is already in place before any new ones are made. This is usually limited to development environments and causes service outages even if it is faster.

Fine-Tuning Rollouts

Two crucial parameters for the RollingUpdate approach can be set to regulate the update’s speed and security:

maxUnavailable: Number of Pods unavailable during update. It uses 25% by default.
maxSurge: Indicates how many Pods can be generated during the update that are more than the specified replica count. This likewise goes to 25% by default.

Monitoring and Managing the Rollout

Several tools can track updates after activation:

Status Monitoring: Kubectl rollout status deployment/[name] provides the latest status.
Pausing and Resuming: Pause a rollout to make several Pod template changes without rollouts. After completion, the rollout restarts to deliver all changes.
Rollover: When you update a Deployment during a rollout, the controller “rollover,” scaling down the previous ReplicaSets and generating a new one.
Rollback: To undo an unstable update, like Pods in an image download cycle, use kubectl rollout undo.

Critical Limitations

Label selectors cannot be altered after apps/v1 API deployment. Changing the option may orphan ReplicaSets since the Deployment must be removed and rebuilt. A Horizontal Pod Autoscaler (HPA) will automatically alter the manifest’s.spec.replicas field based on workload.

You can also read How to install Kubectl in Kubernetes Explained Briefly

Page Content

Tutorials

What are Deployments in Kubernetes? & it’s Use Cases