00

Why "boring" wins

A workload is four files you can read. If you cannot explain the hop from hostname to container port, you do not own the cluster — you rent a dashboard.

01

What we are deploying

Uptime Kuma in its own namespace, one replica, pinned tag, ClusterIP, hostname via ingress.

  • The workload lives in its own namespace — not default.
  • One replica, pinned image tag, readiness probe attached.
  • A ClusterIP Service fronts the pod. Nothing is exposed raw.
  • You verified it with port-forward before trusting the browser.
02

The request path

When you type kuma.bench.local, the request walks this path. Every box to the right of DNS is plumbing you own.

Fig. 01 — Request path, end to endDiagram

Fig. 01 — Request path, end to end

03

The deploy, step by step

  1. STEP01

    Namespace first

    Nothing in this series ships into default.

    Namespace firstyaml
    apiVersion: v1
    kind: Namespace
    metadata:
    name: kuma
  2. STEP02

    Pin the image

    Save the Deployment. If you swap apps later, three lines change: image, port, probe path.

    Pin the imageyaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: uptime-kuma
    namespace: kuma
    spec:
    replicas: 1
    selector:
    matchLabels:
    app: uptime-kuma
    template:
    metadata:
    labels:
    app: uptime-kuma
    spec:
    containers:
    - name: uptime-kuma
    image: louislam/uptime-kuma:1.23.16
    ports:
    - containerPort: 3001
04

When it breaks

Every bad state has a name, and every name has a first command.

SymptomFirst commandWhat you are looking for
ImagePullBackOffkubectl describe pod -n kumaA tag typo, or the node cannot reach the registry.
CrashLoopBackOffkubectl logs -n kuma --previousThe dying words of the last container.
05

Homework

  • Apply the stack and watch the pod cross to 1/1 Running with -w.
  • Hit it via port-forward, then via the hostname.
  • Delete the pod and watch the Deployment conjure a replacement.