Workflows — The Restaurant Daily Routine

The manager has the commands and the vocabulary. Now they need a routine — a shared way of working that keeps the restaurant running smoothly, even when hundreds of customers (requests) arrive.

The Core Loop

The loop has three rules:

1. Declarative, not imperative — describe what you want, not how to do it
2. Observe, don't guess — always verify with kubectl get after applying
3. Rollback fast — if something breaks, undo immediately

Remember

Kubernetes is declarative. You say "I want 3 replicas." If a Pod dies, Kubernetes makes it 3 again — without you doing anything.

Deployment Strategy — Rolling Updates

When you update a container image, Kubernetes doesn't stop all Pods and restart them. It does a rolling update — replacing one Pod at a time.

Update the image

spec:
  template:
    spec:
      containers:
        - name: web
          image: campus-library:1.1.0   # was 1.0.0

Apply the update

kubectl apply -f deployment.yaml

Watch it roll out

kubectl rollout status deployment/campus-library

Waiting for deployment "campus-library" rollout to finish: 1 out of 3 new replicas...
Waiting for deployment "campus-library" rollout to finish: 2 out of 3 new replicas...
deployment "campus-library" successfully rolled out

What happens during the rollout?

1. Kubernetes creates one new Pod with the updated image
2. Waits for it to become Ready
3. Removes one old Pod
4. Repeats until all Pods are updated

If the new Pod fails health checks, Kubernetes stops the rollout and keeps the old Pods running.

Remember

Rolling updates ensure zero downtime. Traffic only reaches healthy Pods.

Rollback — The Emergency Button

See what changed

kubectl rollout history deployment/campus-library

REVISION  CHANGE-CAUSE
1         <none>
2         <none>

Rollback to the previous version

kubectl rollout undo deployment/campus-library

deployment.apps/campus-library rolled back

Rollback to a specific revision

kubectl rollout undo deployment/campus-library --to-revision=1

Remember

Rollback is instant. Kubernetes keeps old ReplicaSets so you can go back. Never deploy without knowing how to rollback.

Autoscaling — Calling More Chefs Automatically

Horizontal Pod Autoscaler (HPA)

Automatically scales the number of Pods based on CPU or memory:

HPA — scale between 2 and 10 Pods

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

When CPU exceeds 70%, Kubernetes adds Pods. When it drops, Kubernetes removes them.

Remember

HPA is the "automatic hiring manager." It scales based on actual load, not guesses.

Probes — Quality Inspections

Kubernetes checks Pod health with three types of probes:

Probe	When	Purpose
Liveness	Continuously	Is the app alive? If not, restart it.
Readiness	Continuously	Is the app ready to receive traffic? If not, remove from Service.
Startup	On boot	Has the app finished starting? Delay liveness/readiness checks.

Probes in a Deployment

spec:
  containers:
    - name: web
      livenessProbe:
        httpGet:
          path: /health
          port: 3000
        initialDelaySeconds: 10
        periodSeconds: 15
      readinessProbe:
        httpGet:
          path: /ready
          port: 3000
        initialDelaySeconds: 5
        periodSeconds: 10

Common mistake

Without probes, Kubernetes sends traffic to Pods that aren't ready yet. Always define readiness probes for production apps.

Resource Limits — Kitchen Capacity

Every chef has limits — they can't use all the kitchen's space and ingredients. Set resource requests (guaranteed minimum) and limits (maximum allowed):

Resource requests and limits

spec:
  containers:
    - name: web
      resources:
        requests:
          memory: "128Mi"     # Guaranteed minimum
          cpu: "250m"         # Guaranteed minimum (0.25 cores)
        limits:
          memory: "256Mi"     # Maximum allowed
          cpu: "500m"         # Maximum allowed

• Request: Kubernetes guarantees this much is available. The Pod is scheduled only if the node has it.
• Limit: The Pod can't use more than this. If it exceeds memory, it's OOM-killed.

Remember

Without resource limits, one Pod can starve others. Always set requests and limits in production.

Config Management — Changing the Recipe

Update a ConfigMap

kubectl create configmap app-config --from-literal=APP_PORT=4000 --dry-run=client -o yaml | kubectl apply -f -

Restart Pods to pick up the new config

kubectl rollout restart deployment/campus-library

Remember

ConfigMap changes don't automatically restart Pods. You need rollout restart or a rolling update to pick up new values.