Kubernetes Deployment Guide

In Kubernetes, "deployment" means two related things: the act of shipping your application to a cluster, and the Deployment object, the API resource that manages it. The Deployment object is how most stateless applications run on Kubernetes; you declare the image, the replica count, and the update policy, and a controller keeps reality matched to that declaration.

What a Deployment Object Does#

A Deployment does not run pods directly. It manages ReplicaSets, which in turn manage pods:

• Desired state: you declare "3 replicas of image v2"; the controller creates or removes pods until the cluster matches
• Self-healing: if a node dies or a pod crashes, the ReplicaSet replaces it without intervention
• Versioned rollouts: each image or config change creates a new ReplicaSet, and old ones are kept as rollback targets
• Controlled updates: changes roll out gradually under rules you set, instead of all at once

A Minimal Manifest#

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/web:1.4.2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/web:1.4.2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080

Apply it and watch the rollout:

kubectl apply -f deployment.yaml
kubectl rollout status deployment/web

kubectl apply -f deployment.yaml
kubectl rollout status deployment/web

The readiness probe is not optional in practice. Kubernetes counts a pod as available once the probe passes; without one, a rollout "succeeds" the moment containers start, whether or not the app inside can serve traffic.

How Rolling Updates Work#

The default strategy is RollingUpdate. When you change the pod template (usually the image tag), Kubernetes creates a new ReplicaSet and shifts pods over in steps, governed by two knobs:

• maxSurge: how many extra pods may exist above the desired count during the update
• maxUnavailable: how many pods may be missing below the desired count

With the defaults (25% each), a 4-replica Deployment updates roughly one pod at a time, keeping capacity near normal throughout. If the new pods never pass readiness, the rollout stalls instead of replacing the fleet with a broken version.

Rolling back is one command, because the previous ReplicaSet still exists:

kubectl rollout undo deployment/web

kubectl rollout undo deployment/web

Deployment Strategies Beyond the Default#

The built-in choices are RollingUpdate and Recreate (kill everything, then start the new version; acceptable only when brief downtime is fine). The strategies teams usually mean by "deployment strategy" are patterns layered on top:

Blue-green and canary need tooling beyond the Deployment object itself: a service mesh, an ingress controller with weighted routing, or a progressive-delivery operator like Argo Rollouts or Flagger.

GitOps: Deployments in Practice#

Most teams stop running kubectl apply from laptops fairly quickly. The common pattern is GitOps: manifests live in a repository, and a controller (Argo CD, Flux) syncs the cluster to whatever the repo declares. A deploy becomes a pull request, which brings review, history, and rollback-by-revert. This is the Kubernetes-native slice of the broader deployment tooling landscape.

Limitations to Know#

• A clean rollout is not a working release. kubectl rollout status confirms pods became ready, not that users can log in, pay, or load the page. Readiness probes check what you wrote into them, nothing more.
• Deployments are for stateless workloads. Databases and anything needing stable identity or ordered startup belong in StatefulSets; batch work belongs in Jobs.
• Strategy sophistication has a floor cost. Canary and blue-green add meshes, operators, and traffic rules that themselves need maintenance and can fail.
• Config changes can hide outside the rollout. A bad ConfigMap or Secret referenced by env vars does not trigger a new rollout by itself, so the breakage appears only as pods restart later.

Best Practices#

• Pin image tags (or digests); latest makes rollbacks and audits guesswork
• Set readiness and liveness probes that test real dependencies, not just process liveness
• Define resource requests and limits so the scheduler and autoscaler have something to work with
• Keep manifests in Git and deploy by sync, not by hand
• Watch the release from the user's side, not just the cluster's side

Conclusion#

A Kubernetes Deployment turns shipping software into a declaration: state the version and replica count, and the controller converges the cluster to it, with rolling updates and one-command rollbacks built in. The strategies above it (blue-green, canary, GitOps) are refinements on that same loop.

The blind spot is that every signal in that loop comes from inside the cluster. ObserveOne checks your endpoints from outside it, so when a rollout goes green but the service does not, you find out from an alert instead of a user.