Installing Kube-Prometheus-Stack on k3s, EKS & Other Distributions

The helm install command for kube-prometheus-stack is identical on every Kubernetes distribution. What differs is everything around it — default StorageClasses, ingress controllers, and security policies vary enough between k3s, EKS, minikube, and OpenShift that persistence and exposure need distribution-specific attention.

What Doesn't Change

The chart, its CRDs, and the install command are identical across every distribution covered here — Prometheus Operator, ServiceMonitor discovery, and Grafana's dashboard provisioning all behave the same way regardless of where the cluster runs. Everything below is about the environment the chart lands in, not the chart itself.

k3s and RKE2

Both k3s and RKE2 ship with the local-path-provisioner as their default StorageClass, backed by node-local disk rather than a networked volume. It works fine for Prometheus and Grafana persistence on a single-node or small cluster, but it doesn't support ReadWriteMany, and a pod using a local-path volume can only be rescheduled back onto the same node — worth knowing before assuming Prometheus can freely move across nodes with its data intact.

k3s also bundles Traefik as its default ingress controller, so a Grafana Ingress resource created without specifying ingressClassName will pick up Traefik automatically rather than needing NGINX installed separately.

Amazon EKS

EKS does not ship a default StorageClass the way k3s does — persistence for Prometheus and Grafana requires the Amazon EBS CSI driver installed as a cluster add-on, plus a StorageClass backed by a gp3 (or gp2) EBS volume type. Without this, prometheus.prometheusSpec.storageSpec and Grafana's persistence settings in values.yaml will create PersistentVolumeClaims that stay Pending indefinitely.

For exposing Grafana externally on EKS, an ALB Ingress (via the AWS Load Balancer Controller) is the typical production path rather than a bare NodePort.

minikube and microk8s

Both are good enough to run the full stack for local development, but the chart's default resource requests assume a real cluster — a laptop-sized minikube or microk8s VM can struggle to schedule Prometheus, Grafana, and Alertmanager simultaneously at default sizing. Reduce prometheus.prometheusSpec.resources and grafana.resources requests in values.yaml before installing rather than after pods start failing to schedule.

microk8s needs its storage and dns addons enabled first (microk8s enable storage dns); minikube ships with a default StorageClass out of the box.

OpenShift

OpenShift's Security Context Constraints (SCCs) are stricter by default than a vanilla Kubernetes cluster's Pod Security Standards. Node Exporter in particular needs host network and host path access to read node-level metrics, which the default restricted SCC does not permit — it typically needs to run under a custom SCC or the hostnetwork SCC bound to its service account.

Prometheus and Grafana containers may also need their SCC to allow the specific UID range the chart's containers expect, since OpenShift assigns a random UID per namespace by default rather than the fixed UID many upstream container images assume.

Frequently Asked Questions

Does kube-prometheus-stack work on k3s?

Yes — the main consideration is that k3s's default local-path storage doesn't support ReadWriteMany or cross-node rescheduling.

What's different about installing on EKS?

EKS needs the EBS CSI driver and a StorageClass configured before persistence will work; there's no default one out of the box.

Does this chart work on OpenShift?

Yes, but Node Exporter and other components typically need a custom Security Context Constraint rather than OpenShift's default restricted policy.

Conclusion

kube-prometheus-stack itself doesn't change between distributions — storage, ingress, and security policy are what actually need distribution-specific attention. Sort out the StorageClass and SCC/ingress situation for your specific platform before installing, and the rest of the chart behaves identically everywhere.