Making a Homelab Kubernetes Cluster Observable

The problem

A cluster can report healthy nodes while workloads struggle. I wanted more context than an occasional kubectl get pods and a consistent place to inspect cluster state over time.

Part of the K3s platform

This is the monitoring layer of the same Proxmox/K3s lab, not a separate unrelated deployment or an employer monitoring system.

Implementation

I installed kube-prometheus-stack into the K3s environment and configured access to Grafana through NGINX Ingress. This provided a practical way to inspect Kubernetes metrics and dashboards while experimenting with workloads and maintenance.

Design and operational tradeoffs

Monitoring should be considered separately from the workloads it observes, while staying within a modest lab's resource budget. Dashboard access also needs protection. A private ingress URL alone does not establish authentication, TLS, durable storage, long-term retention or reliable alert delivery.

Outcome and evidence boundary

The documented work establishes the stack installation and Grafana ingress. No dashboard screenshots, incident measurements or alert-delivery evidence are available in the supplied material. Retention, persistent volumes, external alerts and uptime targets remain unverified.

Lessons learned

Metrics provide context rather than automatic diagnoses. Useful investigation correlates metrics with deployments, logs, node status and actual application symptoms.

Next iteration

• Add actual sanitized node and pod dashboard screenshots.
• Document a specific question answered through metrics.
• Verify retention, storage and alert delivery before making operational claims.