Kubernetes Without the Drama – Part 2: Observability in Action

Last time, we got our app cruising inside MicroK8s — smooth, predictable, like a well-oiled machine.

If you haven’t configured your cluster locally yet, check out Part 1 —

Kubernetes Without the Drama – MicroK8s in Action
.

But here’s the catch: machines don’t talk.

When something slows down or crashes, Kubernetes won’t whisper why.

So, the real question becomes:

What’s Going on in There Right Now?

Sure, Kubernetes is great at keeping things running, but it doesn’t tell you what’s happening under the hood.

It won’t tell you why CPU usage suddenly spiked, which pod decided to take a nap, or when performance started to wobble.

To make sense of that, we need observability — insight into the internal state of the system while it is running.

Observability combines three things:

• Metrics — numerical signals about resource usage and performance.
• Logs — event and application output with context.
• Alerting — awareness when conditions cross thresholds we care about.

Together, these help answer:

• Is the application healthy?
• Is the cluster under load or stress?
• When did something change?
• What was happening right before it did?

There is no shift in workflow (refer to Part 1):

• We still run the cluster inside Multipass.
• We still use Ingress and hostnames to access services from our Mac.
• We still avoid unnecessary Kubernetes complexity.

We’re not rebuilding our setup — we’re adding visibility to it.

In this post, we will:

1. Enable the built-in observability stack.
2. Expose Prometheus, Grafana, and Alertmanager through Ingress.
3. View live cluster metrics, logs, and alerts.

By the end, our cluster won’t just be running —
we’ll be able to understand its state.

1. Enable the Observability Stack

Time to give our cluster some superpowers.

MicroK8s comes with an observability bundle:

• Prometheus for metrics
• Grafana for dashboards
• Alertmanager for alerts
• Loki for logs
• Promtail for log collection

And the best part?

It’s all just one command away:

microk8s enable observability

Grab a coffee while it spins up, then check that everything’s alive:

microk8s kubectl get pods -n observability

You should see Prometheus, Grafana, Alertmanager, Loki, and Promtail happily running.

At this point, the monitoring and logging stack is active inside the cluster, but we can’t access the dashboards yet.

Just like in the previous post, our cluster is running inside a Multipass VM, so we’ll expose these UIs through Ingress and map them to local hostnames.

2. Expose Prometheus, Grafana, and Alertmanager via Ingress

We’ll expose Prometheus, Grafana, and Alertmanager using Ingress — the same approach we used for our app earlier.

Create the Ingress routes:

Grafana

microk8s kubectl create ingress grafana \
  --class=public \
  --rule="grafana.local/*=kube-prom-stack-grafana:80" \
  -n observability

Prometheus

microk8s kubectl create ingress prometheus \
  --class=public \
  --rule="prometheus.local/*=kube-prom-stack-kube-prome-prometheus:9090" \
  -n observability

Alertmanager

microk8s kubectl create ingress alertmanager \
  --class=public \
  --rule="alert.local/*=kube-prom-stack-kube-prome-alertmanager:9093" \
  -n observability

Map the hostnames to the VM:

VM_IP=$(multipass info microk8s-vm | awk '/IPv4/{print $2}')

echo "$VM_IP grafana.local prometheus.local alert.local" | sudo tee -a /etc/hosts

Access the dashboards in your browser:

• 
  http://grafana.local
  
• 
  http://prometheus.local
  
• 
  http://alert.local
  

Default Grafana login:

admin / prom-operator

Sign in, and Grafana greets you with dashboards that reveal your cluster’s heartbeat — metrics, node stats, and pod activity all in one place.

3. Viewing Live Metrics and Logs

With the observability stack up and dashboards exposed, it’s time to peek under the hood and watch your cluster in action.

Open Grafana →

http://grafana.local

Login:

admin / prom-operator

From the left sidebar:

Dashboards → Browse

Look for a dashboard named:

Kubernetes / Compute Resources / Namespace

Select it, then choose the namespace where your application (my-nginx) is running — which is default.

You should now see:

• CPU usage for my-nginx
• Memory usage
• Container restarts
• Pod resource patterns

This is your cluster speaking through metrics.

4. Viewing Logs with Loki

Logs are already flowing into Loki via Promtail, so there’s no extra setup needed — just dive in and explore.

In Grafana:

Explore → (top-left dropdown) → Select "Loki"

Then run a simple query:

{app="nginx"}

You should see:

• Access logs from requests
• Response codes
• Timing and client information

Send traffic again if you want to watch logs stream live:

curl http://demo.local

This gives you both sides of the observability picture:

• Metrics show behaviour
• Logs show context

5. Viewing Alerts

Prometheus and Alertmanager already come with a set of Kubernetes alerts — we don’t need to create anything.

Open Prometheus:

http://prometheus.local

In the top menu, click:

Alerts

You’ll see all the built-in alerts the cluster is evaluating.

If everything is healthy, they’ll show as green or inactive.

If something goes wrong (like a pod repeatedly crashing), the alert will automatically move into a firing state.

From Running to Understanding

You’ve gone from simply deploying workloads to turning blind spots into insights.

With metrics, logs, and alerts at your fingertips, you’re no longer guessing when something feels off — you’re diagnosing it.

Observability isn’t just extra tooling; it’s your window into Kubernetes.

Now, when pods misbehave or performance wobbles, you’ll know why — and fix it before the drama escalates.

So go ahead, open those dashboards, watch the logs stream, and keep an eye on alerts.

Your cluster isn’t just running anymore —
it’s talking, and you’re listening.