Kubernetes works highly distributed manner, as multiple different components are used to deploy an application and ensure that it stays healthy. The smallest unit of Kubernetes is a pod. The container that is running the application code runs inside the pod. One of the major challenges of running an application in pods is that pods are ephemeral by nature. If the pod gets destroyed, it will not be recreated.
Kubernetes has a few ways of ensuring that pods are recreated if they are destroyed. Whenever a pod is destroyed, Kubernetes can recreate it automatically to ensure that the application continues running without any kind of service disruption. This process of self-healing the pod is done by a Kubernetes object known as a deployment.
To learn more about all the different types of Kubernetes workloads, please read this blog.
At scale, managing multiple Kubernetes deployments across multiple regions and clusters can be complex to manage.
Devtron streamlines and automates the entire deployment process, making rollouts faster, safer, and more efficient.
In this blog, we will be taking a deep dive into the Kubernetes Deployment object—what it does, how to create it, and how to implement various deployment strategies using it.
What is a Kubernetes Deployment?
A Kubernetes deployment is an object that helps deploy and run the application in any Kubernetes environment.
It allows you to declaratively define the application's state, such as:
- The image being used,
- Its environment variables,
- The desired number of pod replicas, and more.
Once the Kubernetes deployment is created, the backend of Kubernetes manages the application’s entire lifecycle without requiring any actions from the user.
The Kubernetes Deployment object allows you to templatize the creation of your pods in a declarative manner and helps manage the pods in a way similar to the GitOps approach.
The Deployment object creates and manages the actual pods. In case the pod gets destroyed, the Kubernetes mechanisms take over to re-create the pod and ensure that the cluster is in the desired state.
This removes the manual intervention from users for manually updating and deploying applications, which can be both time-consuming and prone to human error.
If you wish to learn about the different mechanisms of Kubernetes, please check out our blog on the Kubernetes architecture.
The Kubernetes deployment object also supports two deployment strategies out of the box, which help deploy pods with updated configurations while ensuring that there is no downtime for applications.
The two strategies include:
- Rolling updates
- Recreate strategy
Later in this blog, we will be looking at these deployment strategies more in-depth.
Kubernetes Deployments vs Pods
Pods and Deployments are both critical Kubernetes components needed to run applications in any environment. However, both serve two very different purposes.
Pods and Deployments work together to ensure that the application is running at all times.
A Pod is the smallest deployable unit in Kubernetes. Inside a pod, you have the actual application container, which contains:
- The application code,
- Dependencies,
- and other components required to run the application.
A pod also has its own distinct network and storage resources attached to it. These resources are shared between all the containers within the pod.
These pods can host the entire application, or if you're following a microservice architecture, a pod can have an individual component of the entire application.
When a developer or cluster operator creates a pod for running an application, Kubernetes automatically runs and manages the pods.
Once the pod has been defined:
- Kubernetes decides which node each pod should run on.
- It automatically restarts the pod in case it fails.
This process of assigning nodes to pods is known as Kubernetes Scheduling.
Please read this blog to learn about the Kubernetes scheduling mechanisms.
A Kubernetes Deployment object is a tool that helps automatically control and manage the behaviour of pods.
By default, Kubernetes creates only one instance of a pod. If that pod gets deleted, it's gone forever.
Using the deployment object, you can:
- Create multiple instances of the pod
- Automatically recreate pods if the actual number doesn't meet the desired number
Behind the scenes, the Deployment object creates a ReplicaSet to manage the number of running pods.
A Kubernetes deployment object eliminates the need for developers and cluster administrators to manually control the pod’s behavior.
It allows users to declaratively configure all the steps needed to run the pod, including:
- The number of replicas,
- The image to be used,
- The storage resources, and more.
This helps operators save time, as they have to write a single file to apply changes or updates to the entire cluster.
Kubernetes Deployments vs StatefulSets
A StatefulSet is a Kubernetes API Object designed for deploying and managing stateful workloads, such as databases, on Kubernetes.
When a StatefulSet is created:
- Pods are created in a specific order
- A persistent volume is assigned to each pod
- StatefulSets maintain persistent networks, which means the pod’s IP address stays the same even if the pod is deleted or rescheduled
StatefulSets are similar to Deployments in that they both manage the behavior and lifecycle of pods.
However, the key difference is:
- Deployments are designed to run stateless applications
- StatefulSets are meant to run stateful applications
When a StatefulSet is used:
- Each pod has a unique identifier, which enables it to maintain persistent state across its lifecycle
In contrast:
- Pods created by a Deployment have a random value in their name
Pods created by a StatefulSet are numbered sequentially, ensuring each has a consistent identity and can maintain its state.
Kubernetes Deployments vs ReplicaSets
A ReplicaSet is a Kubernetes object that ensures that the pod stays running at all times.
Within a ReplicaSet, you can define a certain number of pods that should be running continuously. The ReplicaSet ensures that the desired number of pods is always met.
The goal of using a ReplicaSet is to:
- Ensure the application has sufficient resources
- Maintain enough pods to handle incoming traffic
When a pod faces an error or is destroyed, the ReplicaSet:
- Immediately creates a new pod to replace the failed one
- Continuously monitors the number of running pods
- Scales pods up or down to match the desired count using the pod template defined in its configuration
A ReplicaSet can also help distribute traffic among the different pods that it creates.
A Kubernetes Deployment, on the other hand, is a higher-level object than a ReplicaSet.
A Deployment is used to manage a ReplicaSet. While a ReplicaSet ensures that a certain number of pods are running, it cannot handle updates to application configurations.
If you want to:
- Change the image version
- Update environment variables
- Roll back to a previous version
A ReplicaSet falls short — but a Deployment can handle all of this declaratively.
Within the official Kubernetes documentation, it is recommended that:
- Users do not directly work with ReplicaSets
- Instead, users should create a Deployment or StatefulSet, which will in turn create and manage the ReplicaSet on their behalf
Kubernetes Deployment Status and Lifecycle
When a Deployment object is created, it goes through a few distinct lifecycle stages. Let’s take a look at how the Deployment progresses from creation to completion (or failure).
Progressing Deployment
- When you create the deployment, it will first enter the progressing state.
- During this phase, Kubernetes begins creating all the necessary objects with the desired components.
Tasks in this stage include:
- Creation of the ReplicaSet
- Scaling of the ReplicaSets
- Creation of the required pods
Complete Deployment
- Once all Kubernetes components are successfully created, the deployment is marked as completed.
- This happens when:
- All ReplicaSets are created (or updated, in case of rolling updates)
- There are no remaining replicas for the older version of the pod
Failed Deployment
- Sometimes, the deployment can encounter issues while creating its pods or ReplicaSets.
- In these cases, the Deployment object will transition to a failed state.
Common causes of deployment failure include:
- Insufficient resource quotas
- Image pull errors
- Readiness probe failures
- Insufficient permissions
- Application runtime misconfigurations
To troubleshoot a failed deployment, you can use the following command:
kubectl rollout status <deployment-name>
What is a Kubernetes Deployment YAML File?
A Kubernetes Deployment YAML file is like a blueprint for your application in the Kubernetes world. Instead of manually creating pods and setting configurations, you describe your app’s desired state in this file — including how many pods you want, which container image to use, and other settings like labels, environment variables, and more.
Once applied using kubectl, Kubernetes takes over and makes sure your cluster reflects what’s written in that file. YAML (Yet Another Markup Language) is readable and structured — perfect for automation, collaboration, and version control.
Think of it as writing down instructions once and letting Kubernetes handle the rest.
How Do I Create a YAML File for Kubernetes Deployment?
Creating a deployment YAML file starts with understanding what your application needs, then translating that into declarative instructions. Most deployment YAMLs follow a standard structure: apiVersion, kind, metadata, spec.
Example of a Basic YAML File
Here’s a minimal example to run an NGINX pod:
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:1.21
ports:
- containerPort: 80
This YAML defines:
- 2 replicas of the NGINX container
- A selector to manage pod identity
- Exposed port 80 inside the container
You can apply this with kubectl apply -f deployment.yaml.
Kubernetes Deployment YAML – Examples
Let’s look at some real-world examples and how they’re used in practice:
Example 1 – Run NGINX Containers Using a YAML File
This example spins up an NGINX deployment with two pods. It's useful when you’re setting up a frontend or proxy service:
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
Ideal for quick web app testing or staging environments.
Example 2 – Use Environment Variables Securely
Passing environment variables is common, but security matters. Avoid placing secrets in plain text. Here’s a simple example:
env:
- name: APP_ENV
value: "production"
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-credentials
key: password
This shows how to:
- Set a simple APP_ENV variable
- Pull sensitive DB_PASSWORD from Kubernetes secrets
Always prefer valueFrom over plain value for anything sensitive.
Example 3 – YAML with Multiple Replicas
Scaling your app is simple with replicas. Here’s how to ensure high availability by running 5 pods:
spec:
replicas: 5
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app:v1.0
Kubernetes will maintain five running pods at all times.
Tired of writing complex YAML files by hand?
Devtron’s UI-based workflows let you deploy applications without ever opening a YAML editor
Kubernetes Deployment Strategy
A deployment strategy is used to progressively roll out application updates without facing service disruptions.
- Recreate Deployment
- Rolling Update Deployment
- Blue/Green Deployment
- Canary Deployment
- A/B Testing
- Shadow Deployment
Recreate Deployment
When using the recreate deployment strategy, all the pods of the older version are instantly destroyed. These pods are then replaced with pods that contain the application's newer configuration. Using this strategy in a production environment is not recommended, as it will lead to significant downtime.
The Recreate strategy should only be used in environments where downtime is acceptable, such as developer environments where the developers may not actively be using the instances.
Rolling Update Deployment
A rolling update deployment strategy is a way to progressively roll out a new application version while ensuring that there is no downtime experienced.
A Kubernetes deployment supports the rolling update strategy out of the box. When using this strategy, the older pods will slowly get replaced by the pods with the newer configurations.
The rolling updates deployment strategy can help you to upgrade applications to newer versions safely and without experiencing downtime. However, the rolling strategy can take some time to fully update every pod depending on the scale of the application. While the deployment is progressing, it can be difficult to trigger a rollback or interrupt the process.
Blue/Green Deployment
The blue/green deployment strategy helps you to quickly switch from an older application version to a newer application version.
This also helps test the newer version in production while ensuring that users can easily be rolled back to a previous version.
The older deployment version is called the “blue” version while the newer version is called as the “green” version.
After the “green” application version is fully deployed to the cluster, you can start routing the traffic from the old “blue” version to the newer “green” deployment. Please check out our in-depth guide on Blue/Green Deployments to learn more about them.
Canary Deployment
Similar to the blue/green deployment, in a canary deployment there are two versions of the application that are deployed at the same time. A small number of users are redirected to the newer version of the application. There are a small number of pods running the new application version to test how it behaves in a production environment. If no major bugs are found in the newer version, the Canary version is gradually expanded until the older version is completely replaced.
Canary deployments are useful for releasing an application to a small group of users and testing it in production environments. In case there are any errors, a canary deployment can easily be rolled back to the previous version. Due to this, Canary deployments are very useful for seeing how newer code will affect the entire system as a whole.
Please check out our blog on Canary Deployments to learn more about them.
A/B Testing
Within the A/B testing deployment strategy, the newer version of the software is released to only a small group of users. While A/B testing is generally confused with blue-green deployments, the two are not the same.
The biggest difference between the two is that the A/B testing strategy is mainly used to test new features in your applications such as a new design, a new UX, noticeability, etc.
The main distinction is that the blue-green strategy is used for actually releasing the updates in batches so that rollbacks are easier to perform in case of any errors. A/B testing on the other hand is for measuring functionality in the application.
Shadow Deployment
When choosing the Shadow deployment strategy, any changes to an application are deployed in a parallel environment that mimics the production environment. The deployed changes are not visible to the end-users, hence the term “shadow.
” This kind of hidden deployment makes it possible to observe the application's behaviour and the impact of its changes without causing any service disruption to the live application.
The primary purpose of shadow deployment is to test real-world application behaviour under load, identify performance bottlenecks, and ensure that the application changes don’t affect the user experience negatively.
It allows developers to test changes in an environment that closely replicates the live production environment, thereby reducing the risk of unforeseen issues cropping up post-deployment.
Shadow deployments provide a safety net to developers and help ensure a smooth transition when the changes are finally deployed to the live environment.
Power Advanced Deployment Strategies—Without ComplexityWhether it's Canary or Blue/Green, Devtron lets you implement them with a few clicks and GitOps automation
Challenges of Kubernetes Deployment Mechanism
Out of the box, the Kubernetes deployment object only supports the Recreate and RollingUpdates deployment strategies. Recreate is not a strategy that can progressively update applications.
It destroys the older version and deploys the newer version which will lead to downtime. RollingUpdates on the other hand can help progressively deliver an application without downtime, but provides only a basic set of safety guarantees during an update.
It is suitable for some application update scenarios but can be lacking in others.
The rolling updates deployment strategy has many limitations such as limited control over the speed of the rollout, cannot control traffic flow to the new version, is not suitable for stress tests or one-time tests, cannot query external metrics to verify an update, and not able to abort and rollback the application update.
In critical production environments, rolling updates that are supported by the Kubernetes deployment object can fall short.
Depending on the configurations of the deployment object, the rollout may occur too quickly and developers may not have adequate time to test the impact of the changes. There is also no automated rollback option if something goes wrong.
Progressive Deployments in Kubernetes with Devtron
Devtron is an open source Kubernetes management platform, that helps you to deploy and manage your applications in any Kubernetes environment.
It makes it very easy to update application configurations and trigger a deployment for the newer version. You can also very easily select your preferred deployment strategy whether you wish to use a Recreate, Rolling Updates, Blue/Green, or Canary deployment strategy.
While creating the deployment pipeline in Devtron, you simply need to select the deployment strategy that you wish to use for delivering application updates.
Devtron will automatically implement the strategy. You can also configure the deployment strategy and set the different configurations such as minimum outages.
Additionally, Devtron helps you easily deploy applications using the GitOps principles. This can help you easily manage application drifts and maintain a history of application configurations in a Git Repository.
FAQ
What exactly is a Kubernetes Deployment, and why should I care?
Think of a Kubernetes Deployment as your app's self-healing manager. It tells Kubernetes how many pods you want, what image to use, and how to keep things running even if something crashes. If you're using Devtron, this process becomes way simpler—you get a visual way to deploy and manage everything, minus the YAML headaches.
Do I really need a YAML file to deploy on Kubernetes?
Technically, yes—Kubernetes uses YAML to understand how to run your app. But writing those files can be tedious. With Devtron, you can either use templates or skip manual YAML altogether and deploy through an intuitive UI. It’s great for teams that want speed without compromising control.
What’s the difference between Deployments, ReplicaSets, and StatefulSets?
Here’s a quick analogy:
- Deployment: Manages stateless apps. Like spinning up web servers.
- ReplicaSet: Makes sure a certain number of pods are always running.
StatefulSet: Manages apps that need memory—like databases. If you’re using Devtron, it handles all these behind the scenes so you can focus on your app, not Kubernetes object relationships.
What deployment strategies can I use in Kubernetes?
By default, Kubernetes gives you two: Rolling Update and Recreate. But if you're aiming for zero downtime or safer rollouts, you’ll want to explore Blue/Green, Canary, or A/B Testing. Devtron supports these advanced strategies out of the box—no extra configuration needed.
How do I check if my deployment is working?
The traditional way? Run kubectl rollout status. But let’s be real—if you prefer seeing logs, pod status, and rollout events visually, Devtron’s dashboard is a lifesaver. It gives you real-time visibility and one-click rollbacks if something breaks.
See Devtron in Action. Discover how top engineering teams simplify Kubernetes management, enforce policies, and scale delivery using Devtron.
Conclusion
Kubernetes deployments provide a great way to deploy, manage, and release updates in a Kubernetes environment.
- They help ensure that application pods always stay running without any downtime. Deployments help abstract and enhance the functions of a ReplicaSet and a consistent number of pods.
- Deployments also help scale the application up or down, and can easily trigger a rollback in case of a faulty application.
- We also saw some of the key differences between deployments and pods, statefulsets, and replicasets.
- Kubernetes also has several deployment strategies that can help progressively roll out application updates without experiencing any downtime.
If you have any questions, or want to discuss any specific usecase, feel free to connect with us or ask them in our actively growing Discord Community.
