🚢 Deploying Applications on Kubernetes

From Code to Cluster

Deploying to Kubernetes is a pipeline: application code becomes a container image, the image plus manifests describe your desired state, and a CI/CD pipeline applies them to the cluster — then you maintain, scale, and observe what's running.

Each stage has decisions to make well. We'll walk them in order: build the image right, package the manifests, roll out safely, scale automatically, and watch it all.

Containerizing for Kubernetes

A good Kubernetes deployment starts with a good image. Follow these principles: one concern per container, run as a non-root user, handle SIGTERM for graceful shutdown, log to stdout/stderr, and keep the image small with a multi-stage build.

# Stage 1 — build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2 — lean runtime image
FROM node:20-alpine
# Create and use a non-root user
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./
USER app
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "dist/server.js"]

Configuration from the environment

Per the Twelve-Factor App, read config from environment variables so the same image runs unchanged across dev, staging, and prod. Validate required values on startup so misconfiguration fails loudly and early:

const config = {
  port: process.env.PORT || 3000,
  dbHost: process.env.DB_HOST || 'localhost',
  dbUser: process.env.DB_USER,
  dbPassword: process.env.DB_PASSWORD,
  logLevel: process.env.LOG_LEVEL || 'info',
};

const required = ['DB_USER', 'DB_PASSWORD'];
const missing = required.filter((key) => !process.env[key]);
if (missing.length > 0) {
  throw new Error(`Missing required env vars: ${missing.join(', ')}`);
}

export default config;

Health-check endpoints

Kubernetes probes need endpoints to hit. Expose a lightweight liveness check and a readiness check that verifies real dependencies:

import express from 'express';
const app = express();

// Liveness: is the process alive?
app.get('/health', (req, res) => res.status(200).send('OK'));

// Readiness: are dependencies reachable?
app.get('/ready', async (req, res) => {
  try {
    await db.ping();
    await redis.ping();
    res.status(200).send('Ready');
  } catch (err) {
    res.status(503).send('Not Ready');
  }
});

Manifests, Helm & Kustomize

You have three main ways to package the YAML you apply to a cluster. Choose by how much environment variation and reuse you need.

1. Raw manifests

Plain YAML applied with kubectl apply -f. Maximum clarity and control — perfect for learning and small apps, but repetitive once you have several environments.

# Imperative (quick, one-off — avoid for production)
kubectl create deployment web --image=nginx:1.27

# Declarative (version-controlled, repeatable — preferred)
kubectl apply -f k8s/

2. Helm — the package manager

Helm packages manifests as reusable, templated charts with a values.yaml for configuration, plus release management and one-command rollbacks.

# Install a public chart
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-nginx bitnami/nginx

# Install your own chart with custom values, then upgrade
helm install my-app ./chart --values prod-values.yaml
helm upgrade my-app ./chart --values prod-values.yaml
helm rollback my-app 1   # instant rollback to revision 1

3. Kustomize — overlays without templating

Built into kubectl, Kustomize keeps a base set of manifests and applies environment-specific overlays as patches — no templating language required.

kubectl apply -k overlays/production/

Deployment Strategies

How you replace the old version with the new one is a real engineering choice, trading resources against safety.

Rolling update (the default)

Kubernetes gradually replaces old pods with new ones, a few at a time, keeping the service up throughout. Tune it with maxSurge (how many extra pods may be created) and maxUnavailable (how many may be down).

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0   # never drop below full capacity

Pros: zero downtime, no extra long-term resources. Cons: both versions run at once during rollout; rollback is gradual, not instant.

Blue-green

Run the new version ("green") fully alongside the old ("blue"), test it, then flip the Service selector to switch all traffic at once. Rollback is instant — flip back.

# Switch traffic by changing one label on the Service
apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web-app
    version: blue   # change to "green" to cut over
  ports:
    - port: 80
      targetPort: 8080

Pros: instant cutover and rollback, full pre-test. Cons: needs double the resources during the switch.

Canary

Send a small slice of traffic (say 10%) to the new version, watch metrics, then ramp up if healthy or pull it if not. In its simplest form you run a small canary Deployment beside the stable one behind the same Service; service meshes (Istio, Linkerd) or Argo Rollouts give you precise percentage control.

Pros: tests with real traffic, limits blast radius. Cons: more moving parts; needs good monitoring to judge "healthy."

Scaling & Autoscaling

You can scale by hand, but the whole point of orchestration is to let the system do it.

# Manual scale
kubectl scale deployment web-app --replicas=5

Horizontal Pod Autoscaler (HPA)

The HPA adds and removes pod replicas automatically based on metrics like CPU utilization or custom application metrics. It's the everyday autoscaler.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

Two companions round out scaling: the Vertical Pod Autoscaler right-sizes CPU/memory requests for a pod, and the Cluster Autoscaler adds or removes nodes when pods can't be scheduled or nodes sit idle. HPA scales pods; Cluster Autoscaler scales the machines under them.

Observability

You can't operate what you can't see. Production observability rests on three pillars — metrics, logs, and traces — plus the health probes that let Kubernetes act on its own.

• Metrics — Prometheus scrapes numeric time-series (request rate, latency, CPU); Grafana visualizes them.
• Logs — a node agent (Fluent Bit) ships container stdout/stderr to a store (Loki or Elasticsearch) you can search.
• Traces — OpenTelemetry follows a single request across many services so you can find the slow hop.
• Alerts — Alertmanager routes threshold breaches to Slack, email, or PagerDuty.

Configure all three probes

Probes are the most immediate form of observability — they let Kubernetes detect and fix problems automatically:

    spec:
      containers:
        - name: web-app
          image: my-registry/web-app:1.0.0
          ports:
            - containerPort: 80
          startupProbe:        # give slow starts time before liveness kicks in
            httpGet:
              path: /startup
              port: 80
            periodSeconds: 2
            failureThreshold: 30
          livenessProbe:       # restart if deadlocked
            httpGet:
              path: /health
              port: 80
            periodSeconds: 10
            failureThreshold: 3
          readinessProbe:      # remove from load balancing until ready
            httpGet:
              path: /ready
              port: 80
            periodSeconds: 5

Hands-on Exercise

apiVersion: v1
kind: Namespace
metadata:
  name: three-tier-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: three-tier-app
spec:
  replicas: 2
  selector:
    matchLabels: { app: backend }
  template:
    metadata:
      labels: { app: backend }
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "3000"
    spec:
      containers:
        - name: backend
          image: my-registry/backend:1.0.0
          ports:
            - containerPort: 3000
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef: { name: mongodb-secret, key: password }
          resources:
            requests: { cpu: "200m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }
          readinessProbe:
            httpGet: { path: /ready, port: 3000 }
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-hpa
  namespace: three-tier-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }

Best Practices

Summary & Quiz

📚 Further Reading

• Kubernetes Deployments (official docs)
• Horizontal Pod Autoscaling
• Helm docs  •  Kustomize docs
• Argo CD — GitOps for Kubernetes

🚀 What's Next?

Your app is deployed, scaling, and rolling out safely. The last piece is keeping it healthy over time. Next up: Application Monitoring Strategies — turning the observability signals we introduced here into dashboards, alerts, and on-call practices.