Kubernetes Deployment Strategies: Types, Examples & YAML Guide

One of today’s most difficult problems facing software engineers is deploying applications. Kubernetes addresses this problem by providing an abstraction layer known as a “deployment”. A deployment is a collection of rules that defines how your application will operate and how to update it.

Rather than tracking individual containers or being concerned with failures, the deployment allows Kubernetes to continually maintain your application in the desired state.

The Kubernetes deployment provides flexibility and control over running your application so that you can manage everything from rolling out minor bugs to releasing without taking your application down.

What Is a Deployment Strategy in Kubernetes?

A deployment strategy is a way for Kubernetes to replace an old version of an application with a new one. It determines how pods are created and deleted, how traffic is routed, and how failures are handled during deployment.

Using the correct strategy will help you:

• Minimise downtime
• Impact users as little as possible
• Identify problems early
• Roll back safely in case of a failure

Each application is different, and each has a different deployment strategy. Several patterns in Kubernetes cater to these needs.

Kubernetes Deployment Architecture Explained

Kubernetes Deployment is not an independent entity; it is used in conjunction with many other fundamental resources in Kubernetes to handle the application’s lifecycle.

Kubernetes Deployment vs Pod

• A pod is the smallest deployable unit in Kubernetes, representing one or more containers that run together on the same node. It contains one or more containers. However, pods are temporary. A Pod by itself is ephemeral and not self-healing. When managed by a controller such as a Deployment or ReplicaSet, failed pods are automatically recreated to maintain the desired state.
• A deployment is used to ensure that pods are always up and running by restarting them if they fail or by updating them when there is a configuration change.

Kubernetes Deployment vs ReplicaSet

• ReplicaSet is used to ensure that a certain number of pod replicas are always up and running.
• A deployment is used to manage ReplicaSets. It handles the following tasks:
  • Creation of a new ReplicaSet
  • Rolling Updates
  • Rollbacks

In other words, you do not need to handle ReplicaSets manually because deployments will handle them automatically.

Kubernetes Deployment vs Service

• A Service provides stable networking and load balancing for pods, while a Deployment manages pod lifecycle, scaling, and version updates.

They work well together:

Deployments create and update pods, while Services automatically route traffic to healthy pods using label selectors.

Kubernetes StatefulSet vs Deployment

• StatefulSets are intended for stateful applications like databases, where pods should have stable identities, persistent storage, and ordered updates.
• Deployments are suited for stateless applications where pods can be created or deleted without restrictions.

Kubernetes DaemonSet vs Deployment

• A DaemonSet guarantees that exactly one pod is running on each node and is suited for system-level daemons like monitoring or logging.
• A deployment is concerned with maintaining a specific number of replicas in the cluster.

Kubernetes Deployment YAML Explained (With Examples)

Basic Kubernetes Deployment YAML Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:latest
          ports:
            - containerPort: 80

This setup specified the following:

• Number of replicas for horizontal scaling
• Label selectors for identifying managed pods
• Pod template that holds information about the image and ports

Key fields in Deployment Spec

replicas – It determines the number of pod instances to be running
selector – It binds the pods to the deployment
Strategy – It determines how the deployment should happen
template – It is a blueprint for creating pods

Here’s an example of rolling update strategy

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

This ensures that the update process is done gradually, and the application is always available during the upgrade process.

Kubernetes Deployment Environment Variables

You can dynamically inject configuration into containers:

env:
  - name: ENVIRONMENT
    value: production

To achieve this in production, environment variables are normally calculated from ConfigMaps and Secrets, which facilitate:

• Secure configuration management.
• Configuration isolated to an environment.
• Flexible ways to update without rebuilding images.

Types of Kubernetes Deployment Strategies

Recreate Deployment Strategy

In this strategy, all the existing pods are stopped before the new pods are started. This strategy is very simple, but it results in downtime, so it is not recommended for critical applications.

Rolling Deployment (Rolling Update)

In this strategy, the pods are updated one by one. This means that some pods are always up and running. This is the default strategy in Kubernetes and is recommended for most stateless applications.

Blue-Green Deployment in Kubernetes

Blue-green deployments are not natively supported by Kubernetes and are implemented using Services, Ingress controllers, or service meshes (such as Istio). Traffic is switched from the old version to the new version by updating routing rules. This strategy is recommended for quick rollbacks in case of problems.

Canary Deployment Kubernetes

A canary deployment gradually routes a portion of traffic to the new version. This is usually achieved using multiple Deployments combined with Ingress rules, service meshes, or load balancers.

A/B Testing Deployment

In this strategy, two or more versions are deployed at the same time. Each version is accessed by a different set of users. This method is very common for feature testing and performance comparison.

Shadow Deployment

It deploys new versions to production but routes them in such a way that real users are not impacted. Shadow deployments typically mirror production traffic in a read-only or isolated manner to avoid side effects such as duplicate writes.

Ramped Slow Rollout

This strategy increases traffic in stages, verifying outcomes at each point.

Best-Effort Controlled Rollout

Pod updates are carefully controlled, moving slowly with a focus on stability rather than speed.

These are conceptual rollout patterns implemented using rolling updates, traffic management tools, or progressive delivery platforms rather than native Kubernetes features.

Choosing the Right Kubernetes Deployment Strategy

Stateless Applications

Rolling updates or canary releases provide a good balance between safety and speed.

Stateful Applications

StatefulSets with controlled updates are recommended to maintain data integrity.

High-Traffic Applications

Canary or blue-green deployments are the most effective in reducing risks and impact on users.

Mission-Critical & Zero-Downtime Deployments

Blue-green or progressive canary deployments are the most suitable in such scenarios.

Batch Jobs & Background Workers

Recreate or rolling update strategies are often sufficient.

Kubernetes Update, Scaling & Restart Strategies

Kubernetes Scale Deployment

It’s easy to increase your deployment’s size; by horizontally scaling, you can improve your application’s availability, fault tolerance, and ability to handle spikes in traffic.

kubectl scale deployment web-app --replicas=5

Rollbacks, Deletions & High Availability

Rollbacks

kubectl rollout undo deployment web-app

If a deployment fails, it quickly falls back to the last good version that was running.

Delete

kubectl delete deployment web-app

To achieve high availability

1. Use multiple replicas
2. Spread out your pods across different nodes
3. Use rolling or canary updates.
4. Set up readiness probes and liveness probes.

Kubernetes Continuous & Automated Deployments

Kubernetes can be easily integrated with CI/CD pipelines because it automatically deploys application updates once the code is built and tested.

The CI process is responsible for building container images and executing tests, while the CD process is responsible for updating Kubernetes deployments through declarative configuration. This makes the princess error-free and enables faster deployment of changes.

Kubernetes Deployment Tools & Platforms

Common tools improve Kubernetes deployments by providing better control, safety, and visibility during the deployment process.

• Git-based workflows enable version control of Kubernetes configurations, ensuring that all changes are traceable, auditable, and easily reversible. This makes collaboration easier and maintains consistency in the cluster state.
• Progressive delivery controls enable the gradual delivery of updates via canary or blue-green deployments, which are safer and help identify issues early on.
• Deployment visibility and metrics enable real-time visibility into the status of the deployment, pod health, and application performance, which helps to quickly identify and resolve issues.

Terraform Kubernetes Deployment

Infrastructure as Code is possible through Terraform. You can configure your Kubernetes clusters and deployments as Configuration Files (Code).

You can then take that same configuration and use it with minor modifications for your development and production environments to maintain consistency between environments and help prevent configuration drift.

Real-World Kubernetes Deployment Example

In actual production setups, rollouts are hardly done using a single approach. Instead, several methods are employed together to minimise risks while still being able to deliver at high speeds.

• Rolling updates are employed for regular deployments, enabling pods to be updated incrementally while ensuring the application remains running.
• Canary deployments are employed for large or high-risk updates, where the new version is first made available to a small amount of traffic.
• Auto-scaling allows pod replicas to be adjusted automatically depending on traffic or resource utilisation for optimal performance.

Kubernetes Deployment Documentation & Best Practices

• Use declarative YAML field: Specify what you want, not how to get it; Kubernetes takes care of ensuring your cluster is in the desired state.
• Store configuration in version control: track changes, collaborate, and easily roll back if necessary.
• Define health probes: Liveness readiness and startup probes help keep pods and traffic healthy.
• Monitor rollout status: Monitor deployments in real time to detect issues early and roll back quickly.
• Keep deployments small and incremental: Deploy changes in small increments to minimise risk and simplify debugging.

FAQs: Kubernetes Deployment

What are Kubernetes deployments?

They are controllers that manage your pods, ensuring the desired number of replicas run, updates are done safely, and rollbacks are possible if something goes wrong.

How to deploy a project on Kubernetes?

You create a deployment YAML, apply it and expose it with a service to access it.

What can be deployed on Kubernetes?

Any type of containerised workload: web applications, APIs, background workers, batch jobs, microservices, and even databases with StatefulSets.

What are the deployment types in Kubernetes?

Recreate rolling updates, blue-green, canary, A/B testing, and shadow deployments.

Conclusion: A Balanced Approach to Kubernetes Deployments

When you deploy an application using Kubernetes, it will ensure that your application is deployed reliably at scale via automatic management of pods to keep your app running in its intended state.

Using deployment strategies, rolling-update strategies, canary releases, and accurate YAML and automation will provide your team with quicker deploys with maintainable application stability, resilience and availability.

Shivam Mahajan

Shivam Mahajan is an editor skilled in SysOps, Tech, and Cloud. With experience at AttuneOps and other companies, he simplifies complex technical material for easy understanding.