Deployment

What Does Deployment Mean?

A Deployment in Kubernetes is a controller that manages pods and keeps the desired number of replicas running. If a pod fails, the Deployment replaces it automatically.

Deployments are the foundation for running stateless applications. They provide a declarative way to define application state, so teams focus on the app instead of pod management.

How Deployments Work in Kubernetes

A Deployment is defined in YAML. It sets replicas, a pod template, selectors, and an update strategy:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: billing-api
  template:
    metadata:
      labels:
        app: billing-api
    spec:
      containers:
        - name: billing-api
          image: registry.example.com/billing-api:1.4.2
          ports:
            - containerPort: 8080

• Replicas: how many identical pods should run
• Pod template: image, environment variables, and resource requests and limits
• Update strategy: rolling updates or recreate
• Selector labels: which pods belong to the Deployment
• Health probes: liveness and readiness checks

Kubernetes continuously reconciles the actual state with this desired state.

Pod vs. ReplicaSet vs. Deployment

Why Deployments Matter

• High availability: replicas spread across nodes keep apps reachable
• Scalability: change replica counts or use autoscaling
• Resilience: failed pods and nodes are replaced automatically
• Safe updates: rolling updates and rollbacks reduce release risk

Without Deployments, teams would manage pods by hand, which is error-prone and slow.

Common Deployment Patterns

• Rolling updates: replace pods gradually for zero downtime
• Canary deployments: send a little traffic to a new version first
• Blue-green deployments: switch traffic between two full environments
• Resource management: requests and limits prevent exhaustion
• Pod disruption budgets: limit unavailable replicas during maintenance

Real-World Example

A B2B SaaS team rolls out a new billing API version with a rolling update. After the rollout completes, a Testkube workflow runs API and smoke tests against the new pods.

When a test fails, the team runs kubectl rollout undo and restores the previous version in seconds.

How Deployments Relate to Testkube

Testkube is Kubernetes-native. Its long-running services, such as the agent and API components, run as Deployments.

• Reliable services: core components restart automatically after failures
• Safe upgrades: rolling updates keep Testkube available during upgrades
• Isolated test runs: each test execution runs as its own Job and pod
• Post-rollout testing: workflows can validate your Deployments after every change

Testkube fits existing monitoring, logging, and GitOps tooling because it uses standard primitives.

Best Practices for Deployments

• Set probes: readiness and liveness probes guide safe rollouts
• Define resources: requests and limits keep scheduling predictable
• Pin image versions: avoid latest for reproducible rollouts
• Test after rollouts: validate new versions before shifting traffic
• Manage with GitOps: version Deployments and roll back by commit

Frequently Asked Questions (FAQs)