Quick summary (what the Helm chart installs)
- StatefulSets: Prometheus server, Alertmanager
- Deployments: Prometheus Operator, kube-state-metrics, Grafana
- ReplicaSets: associated with the Deployments above
- DaemonSet: node-exporter (one pod per node)
- Services: ClusterIP services for internal access
- Secrets / ConfigMaps: generated Prometheus config and rule files
The Helm chart also installs Grafana and configures it to use the Prometheus datasource out of the box. Grafana provides a graphical UI to visualize Prometheus metrics (installed automatically by the chart).
Inspect the cluster resources
Run:Resource summary table
StatefulSets (Prometheus & Alertmanager)
Start from the bottom ofkubectl get all output: the StatefulSets are the Prometheus server and Alertmanager.
List StatefulSets:
- Prometheus container args (web UI, storage path, config file)
- Init container:
prometheus-config-reloader(creates initial config) - Sidecar/container: config reloader (watches config changes and triggers Prometheus reload)
- Mounts and Volumes (where Prometheus YAML and rule files come from)
Deployments and ReplicaSets
Key deployments:prometheus-kube-prometheus-operator— the Prometheus Operator container that manages Prometheus instances and their lifecycle.prometheus-grafana— Grafana UI.prometheus-kube-state-metrics— exposes Kubernetes object metrics (deployments, pods, etc).
DaemonSet — node-exporter
The chart creates a DaemonSet called something likeprometheus-prometheus-node-exporter. DaemonSets ensure one node-exporter pod runs on each cluster node and expose host metrics (CPU, memory, filesystem) for Prometheus to scrape.
Check nodes and daemonset status:
Pods and Services
Pods section shows all pods created (Prometheus, Alertmanager, Grafana, Operator, kube-state-metrics, two node-exporters). Services created are typically ClusterIP (internal) by default:- Create an Ingress
- Change the Service type to
LoadBalancer - Use
kubectl port-forwardorkubectl proxyfor quick local access
Where the Prometheus configuration and rule files live
The Prometheus Operator generates the Prometheus configuration and stores it in a Secret (gzippedprometheus.yaml.gz) that is mounted into the Prometheus pod. Rule files are stored in a ConfigMap.
To inspect the Secret containing the generated Prometheus config:
Do not manually edit the generated Secret or ConfigMap created by the operator. Changes will be overridden by the operator. Instead, use Kubernetes-native objects supported by the Prometheus Operator (ServiceMonitor, PodMonitor, PrometheusRule, Prometheus CR) to configure scraping and rules.
How the config reload workflow works
- The Prometheus Operator generates
prometheus.yamland writes it into a Secret. - The Prometheus StatefulSet mounts that Secret into
/etc/prometheus/config. - An init container (
init-config-reloader) and a sidecarprometheus-config-reloaderwatch the config/rule mounts (ConfigMap / Secret / EmptyDir). - When a change is detected, the reloader triggers Prometheus’
/-/reloadendpoint so Prometheus applies the updated configuration without manual restarts.
PrometheusRule objects vs editing the generated files
Use Prometheus Operator resources (PrometheusRule) to add or modify alerting and recording rules. The operator will render these into the rule ConfigMap(s) and mount them into Prometheus. This is the recommended pattern — it avoids manual edits to the generated artifacts. Example: create aPrometheusRule manifest and apply with kubectl apply -f myrule.yaml. The operator merges it into the rule ConfigMap.
Quick commands cheat-sheet
Useful links and references
- Prometheus Operator docs: https://github.com/prometheus-operator/prometheus-operator
- Prometheus Operator runbooks and rules: https://prometheus-operator.dev/
- Kubernetes kubectl docs: https://kubernetes.io/docs/reference/kubectl/overview/
If you’d like, I can:
- Show an example
PrometheusRulemanifest and walk you through adding an alert, or - Provide a sample
ServiceMonitorto scrape a custom app and demonstrate how the operator renders the config.