Lesson 02 · Serving

Deploy your first site

Put a real website on the cluster and reach it from a browser — tracing the whole request path: Pod → Deployment → Service → Ingress. This is the skeleton every site you ever host will use.

The mental model: the request path

One HTTP request from your browser travels right to left through four objects. Read it as a sentence: an Ingress routes a hostname to a Service, which load-balances to Pods, which a Deployment keeps alive.

Pod — the unit that runs

The smallest deployable thing: one (or a few) containers sharing an IP and storage. Pods are cattle, not pets — disposable, and their IP changes when they're recreated.

Deployment — the controller that keeps them running

You don't create Pods directly. You declare a Deployment: "I want 2 replicas of this Pod template." Its controller continuously reconciles reality to that desire — kill a Pod and it makes a new one; change the image and it rolls the change out gradually.

Service — the stable front door

A Service gives a stable virtual IP + in-cluster DNS name. It finds its Pods by label selector (not by IP) and load-balances across them. Default type ClusterIP = reachable only inside the cluster.

Ingress — the HTTP router at the edge

An Ingress is an L7 rule: "requests for host hello.local go to Service hello-site." It's executed by an ingress controller (the microk8s enable ingress addon — Traefik on 1.35+, exposed via the public IngressClass). One controller can route many hostnames → one site each.

Do it — on the machine that talks to your cluster

$ microk8s enable dns ingress
$ kubectl get ingressclass        # confirm a class exists; we'll use "public"

apiVersion: apps/v1
kind: Deployment
metadata: { name: hello-site }
spec:
  replicas: 2
  selector: { matchLabels: { app: hello-site } }
  template:
    metadata: { labels: { app: hello-site } }   # Pods get this label…
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports: [ { containerPort: 80 } ]
---
apiVersion: v1
kind: Service
metadata: { name: hello-site }
spec:
  selector: { app: hello-site }                 # …Service finds Pods by it
  ports: [ { port: 80, targetPort: 80 } ]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: hello-site }
spec:
  ingressClassName: public
  rules:
    - host: hello.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: hello-site, port: { number: 80 } }

$ kubectl apply -f hello-site.yaml
$ kubectl get deploy,pods,svc,ingress     # the whole chain at once
$ kubectl rollout status deploy/hello-site

$ multipass list                          # grab the VM IP, e.g. 192.168.64.5
# add to /etc/hosts on the machine with the browser:
$ echo "192.168.64.5  hello.local" | sudo tee -a /etc/hosts
$ curl http://hello.local/                 # or open it in a browser

Debug like you mean it

Your mission is to fix things with kubectl, not guess. When a site is down, walk the chain with these four verbs:

$ kubectl get pods                         # Running? CrashLoop? Pending?
$ kubectl describe pod <name>               # events at the bottom tell the story
$ kubectl logs <pod>                        # what the app itself printed
$ kubectl get events --sort-by=.lastTimestamp   # cluster-wide recent history