Skip to main content
We installed the Prometheus Helm chart (kube-prometheus-stack). Let’s inspect what it created and where the important configuration and rule files live. This guide walks through the main resources, how they map to Prometheus components, and the exact commands to inspect and extract configuration for editing.

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:
Example output (trimmed for readability):

Resource summary table


StatefulSets (Prometheus & Alertmanager)

Start from the bottom of kubectl get all output: the StatefulSets are the Prometheus server and Alertmanager. List StatefulSets:
Example:
Describe the Prometheus StatefulSet to inspect containers, args, mounts, and volumes:
You can pipe the full description to a file for easier viewing in an editor:
Key sections you’ll see in the StatefulSet description:
  • 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)
Example container args extracted from the StatefulSet (trimmed):
Init container (responsible for initial config):
The StatefulSet mounts show where the config, rule files, and web config live:

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).
Describe the operator deployment:
Important flags you’ll see for the operator:
The operator primarily watches Kubernetes API objects (Prometheus, ServiceMonitor, PodMonitor, PrometheusRule, etc.) and generates the Prometheus configuration, rule files, and Secrets/ConfigMaps used by the Prometheus StatefulSet.

DaemonSet — node-exporter

The chart creates a DaemonSet called something like prometheus-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:
If you want to access Prometheus or Grafana externally you can:
  • Create an Ingress
  • Change the Service type to LoadBalancer
  • Use kubectl port-forward or kubectl proxy for quick local access

Where the Prometheus configuration and rule files live

The Prometheus Operator generates the Prometheus configuration and stores it in a Secret (gzipped prometheus.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:
Example Secret description:
To inspect rule files (ConfigMap with alerting/recording rules):
A rulefile excerpt will look like:
If you prefer to view the raw generated file locally, dump the secret and extract the gzipped YAML:
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.yaml and writes it into a Secret.
  • The Prometheus StatefulSet mounts that Secret into /etc/prometheus/config.
  • An init container (init-config-reloader) and a sidecar prometheus-config-reloader watch the config/rule mounts (ConfigMap / Secret / EmptyDir).
  • When a change is detected, the reloader triggers Prometheus’ /-/reload endpoint so Prometheus applies the updated configuration without manual restarts.
Reloader config example (from the StatefulSet):

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 a PrometheusRule manifest and apply with kubectl apply -f myrule.yaml. The operator merges it into the rule ConfigMap.

Quick commands cheat-sheet



If you’d like, I can:
  • Show an example PrometheusRule manifest and walk you through adding an alert, or
  • Provide a sample ServiceMonitor to scrape a custom app and demonstrate how the operator renders the config.

Watch Video