Skip to content
M
All projects
Observability2025YAML / Bash

Grafana on Kubernetes

A small, repeatable way to keep dashboards alive.

View repositoryMore projects
Grafana
9.5.21
Storage
15 GiB, RWO
Manifests
6
Commits
1 (squashed)
Updated
Dec 2025
License
None

System

How it fits together.

A simplified view of the moving parts, not a full architecture diagram.

  1. 01Ingressnginx class, optional
  2. 02ServiceClusterIP 80 → 3000
  3. 03Grafana Pod9.5.21, probes, limits
  4. 04PVC15 GiB, ReadWriteOnce

Context

Why it exists.

Grafana is easy to start and easy to lose. This deployment package makes its storage, configuration, and network exposure explicit so a rescheduled pod does not take the dashboards with it.

Approach

  1. 01Separate namespace, PersistentVolumeClaim, Deployment, Service, and Ingress.
  2. 02Mount the claim at nine subpaths so configuration, plugins, dashboards, and data each have an explicit location.
  3. 03Add readiness and liveness probes plus requests and limits instead of accepting defaults.
  4. 04Keep a busybox pod and a hostPath PersistentVolume for inspecting storage locally.

Inside the repository

What is actually in there.

Explicit resources

Requests of 500m CPU and 1 GiB, limits of 2 CPU and 4 GiB, with fsGroup 472 for the Grafana user.

Nine subPath mounts

The volume is split across data, config, plugins, public assets, docs, and tooling paths rather than one opaque mount.

Health checks

Readiness reads /robots.txt on port 3000; liveness uses a TCP socket check.

Bootstrap script

StartServices.sh creates the namespace and applies the PVC and Deployment; service and ingress lines are intentionally commented out for review first.

Constraints & notes

The storage class is gp3, so it needs AWS EBS or a manual edit. The ingress hostname and local hostPath PV are machine-specific, and this is a set of manifests rather than a Helm chart. No license file is present.