Skip to content

Deploying object

Kubernetes Deployments are a crucial object that provides declarative updates for Pods and ReplicaSets. They act as a top-level object or a manager (like a general manager or supervisor) that controls ReplicaSets, which in turn control Pods. This hierarchy offers significant advantages, especially when dealing with application updates and rollbacks.

Historically, ReplicaSets and Replication Controllers were not able to handle application updates or rollbacks effectively in real-time environments. For instance, if an update to an application like WhatsApp or Facebook caused issues, there was no straightforward way to revert to a previous, stable version. Deployments were created to address this limitation.

How Deployment Works and its Core Functionality#

When you use a Deployment, you define the desired state of your application. The Deployment object then monitors the cluster to ensure that this desired state is maintained.

  1. Controlling ReplicaSets: A Deployment controls ReplicaSets. When you apply changes to your application's code or configuration through a Deployment, it creates a new ReplicaSet for each new version. For example, if you have an application running as Version 1 (V1) under ReplicaSet-V1, and you update your code, the Deployment will create ReplicaSet-V2 to manage the new version, while maintaining a record of V1. This process allows Deployment to maintain multiple versions of your application.
  2. Pod Management: ReplicaSets are responsible for creating and maintaining the desired number of Pods. If you specify two replicas, the ReplicaSet will ensure two Pods are running at all times. If a Pod fails or is deleted, the ReplicaSet will automatically create a new one to maintain the desired count, a mechanism known as self-healing.
  3. Updates and Rollbacks: Deployments provide fine-grained control over how new Pods are rolled out, updated, or rolled back to a previous state. When you update an application through a Deployment, it will gracefully move Pods from the old ReplicaSet to the new one. The old ReplicaSet is typically stopped but kept as a version for potential future rollbacks.

An important concept to remember during rollbacks is that while the code or application version reverts to an older state, the number of Pods remains the same as in the current state. For example, if your current deployment is running on four Pods and you roll back to a version that previously ran on only one Pod, the application on all four current Pods will revert to the old code, but all four Pods will continue to run.

Key Features and Use Cases of Deployments#

Deployments offer several powerful features and use cases:

  • Rolling Out New Versions: You can declaratively update your Pods and ReplicaSets to roll out a new version of your application.
  • Declaring New States: You can define a new desired state for your Deployment by updating its Pod template specification. This will create a new ReplicaSet and manage the transition of Pods from the old ReplicaSet to the new one.
  • Monitoring Rollout Status: Deployments allow you to check the status of a rollout to see if it succeeded or not.
  • Rolling Back to Previous Revisions: If a new update causes issues, you can easily roll back to any previous version of your application that the Deployment has maintained.
    • To undo the last rollout, you can use the kubectl rollout undo command.
    • To roll back to a specific revision, you can use kubectl rollout undo deploy <deployment-name> --to-revision=<number>.
  • Scaling: Deployments facilitate scaling up (increasing the number of Pods) and scaling down (decreasing the number of Pods) to manage workload. For example, you can scale from two Pods to four, or from four Pods down to two. When scaling down, the Pods that were most recently created are typically deleted first.
  • Pausing and Resuming: Deployments can be paused to apply multiple updates to a Pod template specification or to make configuration changes without triggering rollouts. Once changes are complete, the Deployment can be resumed.
  • Cleaning Up Old ReplicaSets: Deployments help in managing and cleaning up old, unneeded ReplicaSets.

Practical Examples and Commands#

To demonstrate Deployment functionality, let's look at some conceptual YAML structures and command-line instructions.

1. Deployment YAML Structure#

A Deployment is defined in a YAML file. The kind field specifies Deployment, and other fields define its behavior, such as the number of replicas, the container image, and commands to run.

apiVersion: apps/v1
kind: Deployment # Specifies the object type as Deployment
metadata:
  name: my-deployment # Name of the Deployment object
spec:
  replicas: 2 # Desired number of Pod replicas
  selector:
    matchLabels:
      app: my-deployment # Labels to select Pods managed by this Deployment
  template:
    metadata:
      labels:
        app: my-deployment # Labels applied to Pods created by this Deployment
    spec:
      containers:
      - name: my-container # Name of the container
        image: ubuntu # Container image to use, e.g., 'ubuntu' or 'centos'
        command: ["/bin/bash", "-c", "while true; do echo 'Technical Guftgu'; sleep 5; done"] # Command to run inside the container

2. Deploying Your Application#

After creating the YAML file (e.g., my-deploy.yaml), you apply it to your Kubernetes cluster:

  • Create/Edit YAML file: vi my-deploy.yaml
  • Apply the Deployment: kubectl apply -f my-deploy.yaml
    • This command will create the Deployment, which in turn creates a ReplicaSet, and then the specified number of Pods.

3. Checking Deployment Status and Details#

You can verify the status and details of your Deployment, ReplicaSets, and Pods using kubectl commands:

  • Check Deployment status: kubectl get deploy
    • This command shows the Deployment name, how many Pods are READY (e.g., 2/2 means 2 are ready out of 2 desired), how many are UP-TO-DATE, how many are AVAILABLE, and the AGE of the Deployment.
  • Describe a Deployment for detailed information: kubectl describe deploy my-deployment
    • This provides extensive details about the Deployment, including its configuration, events, and related ReplicaSets and Pods.
  • Check ReplicaSet status: kubectl get rs
    • This shows details for ReplicaSets, including DESIRED, CURRENT, and READY Pod counts.
  • Check Pod status: kubectl get pods
    • This lists the Pods, their STATUS, RESTARTS, and AGE. Pod names created by a Deployment will typically start with the Deployment name followed by a random string.
  • View logs inside a container: kubectl logs -f <pod-name>
    • This allows you to see the output of the command running inside a specific Pod's container.
  • Execute a command inside a container (e.g., to check OS release): kubectl exec <pod-name> -- cat /etc/os-release

4. Scaling Deployments#

You can easily scale your Deployment up or down:

  • Scale up: kubectl scale --replicas=4 deploy my-deployment (changes the desired number of Pods to 4)
  • Scale down: kubectl scale --replicas=1 deploy my-deployment (changes the desired number of Pods to 1)

5. Updating and Rolling Back Deployments#

To update your application, modify the image or command in your my-deploy.yaml file, then reapply it:

  • Modify my-deploy.yaml (e.g., change image: ubuntu to image: centos or update the command output).
  • Reapply the file: kubectl apply -f my-deploy.yaml
    • This will create a new ReplicaSet for the updated version, and Pods will be transitioned.
  • Check rollout history: kubectl rollout history deploy my-deployment
    • This command shows the revision history of your Deployment, indicating how many times you've made and applied changes.
  • Rollback to the previous version: kubectl rollout undo deploy my-deployment
    • This command reverts the Deployment to the immediately preceding version.
  • Rollback to a specific version: kubectl rollout undo deploy my-deployment --to-revision=2 (reverts to revision number 2).

Potential Deployment Failure Scenarios (Interview Focus)#

During an interview, you might be asked about reasons for Deployment failures. Here are some common scenarios:

  • Insufficient Quota: Not enough resources (CPU, memory) are available in the cluster or on the nodes.
  • Unhealthy Nodes: The Kubernetes nodes where Pods are scheduled are not in a healthy state or are down.
  • Image Pull Errors: The specified container image cannot be pulled from the registry. This could be due to incorrect image name/tag, private registry authentication issues, or the image not existing.
  • Insufficient Permissions: The service account or user deploying the application lacks the necessary permissions to create or manage Kubernetes resources.
  • Limit Ranges: Resource limits defined (e.g., CPU or memory) are exceeded, preventing Pods from being scheduled or starting.
  • Application Runtime Misconfiguration: Issues within the application code or its configuration prevent it from starting or running correctly within the container.
  • kubectl connection issues: Problems with the kubectl setup (e.g., issues accessing the cluster using putty due to incorrect key format) can prevent commands from executing.

These are the main concepts and practical aspects of Kubernetes Deployments as discussed in the provided sources.