Skip to main content
You’ve installed the Helm chart for the kube-prometheus stack. The next step is to inspect the Kubernetes resources the chart created so you can understand how Prometheus, Alertmanager, Grafana, the operator, and node exporters are laid out inside the cluster.

List resources created by the Helm chart

Run this to list pods, services, daemonsets, deployments, statefulsets, and replicasets in the current namespace:
Example condensed output (trimmed for clarity):

High-level mapping of resources

  • The Pods list should show Prometheus, Alertmanager, Grafana, the operator, kube-state-metrics, and one node-exporter pod per node.
  • The Services created by the chart are primarily type ClusterIP (reachable only inside the cluster by default).
If you need to access Prometheus or Grafana from outside the cluster, you must either:
  • Change a service to LoadBalancer, or
  • Add an Ingress that routes to the service, or
  • Use kubectl port-forward as a quick, local option.

Inspecting the Prometheus StatefulSet

To review the Prometheus StatefulSet and see how the Prometheus process and its sidecars are configured:
  1. List StatefulSets:
  1. Save a describe to a file for easier review:
Key excerpts from the StatefulSet describe output: Prometheus main container arguments and flags:
Init container (generates initial config files):
Config reloader sidecar (keeps Prometheus config in sync and triggers reloads):

Where Prometheus config and rules come from

  • The Prometheus configuration is generated by the Prometheus Operator and injected into the pod via a Secret mounted at /etc/prometheus/config.
  • Alerting and recording rules are rendered into ConfigMaps and mounted under /etc/prometheus/rules/....
Inspect the Secret that contains the generated Prometheus YAML:
Example output (Secret contains a gzipped prometheus.yaml):
Inspect the ConfigMap containing rule files (save to file for easier reading):
Example rule group excerpt (from the generated ConfigMap):
Note: The Prometheus Operator is responsible for generating these Secrets and ConfigMaps. Do not edit the generated Secrets or ConfigMaps directly. Instead, modify scraping targets and alerts declaratively using the Operator CRDs (for example, ServiceMonitor, PodMonitor, PrometheusRule).

Inspecting the Prometheus Operator deployment

List deployments in the namespace:
Save the operator describe to a file for review:
Key operator container args, TLS and mounts:
Operator responsibilities:
  • Reconcile Prometheus, Alertmanager, and related resources based on higher-level CRDs.
  • Generate the Prometheus YAML configuration (stored in Secrets) and rule ConfigMaps from CRD manifests.
  • Manage configuration reloads and restarts (via config-reloader sidecars).
  • Provide extensibility points such as ServiceMonitor, PodMonitor, and PrometheusRule CRDs for declarative configuration.

Best practices and wrap-up

  • Prefer using the Operator CRDs (ServiceMonitor, PodMonitor, PrometheusRule) to add scrape targets and alerting/recording rules.
  • Do not edit generated Secrets or ConfigMaps directly; changes will be overwritten by the Operator.
  • To access Prometheus or Grafana externally, expose services via LoadBalancer, set up an Ingress, or use kubectl port-forward for quick local access.
  • Monitor the prometheus StatefulSet and the prometheus-operator Deployment for health and restart events.
If you want, I can provide example ServiceMonitor and PrometheusRule YAML to add a basic scrape target and an alert rule using the Operator CRDs.

Watch Video