Grafana Helm Chart v4 for Kubernetes Monitoring

Kubernetes monitoring usually starts simple, then gets messy when teams add more clusters, more destinations, and more GitOps overlays. Grafana's Kubernetes Monitoring Helm chart v4 is interesting because it fixes several scaling problems in the chart's configuration model instead of only adding more toggles.

What Is the Grafana Kubernetes Monitoring Helm Chart?

The chart installs Grafana Alloy collectors and related configuration for sending Kubernetes metrics, logs, traces, and profiles to Grafana Cloud or a self-hosted Grafana stack. Grafana Labs describes v4 as the chart's biggest update so far, built after months of work on problems reported by larger deployments.

The theme is predictability. Values that were previously hidden, positional, or overloaded are now explicit and easier to compose across environments.

Key Changes

• Destinations are maps: Prometheus, Loki, and other targets now have stable names instead of list positions, which makes Helm overrides safer in Argo CD, Flux, and Terraform workflows.
• Collectors are explicit: Teams define named collectors with presets such as clustered, statefulset, daemonset, and filesystem-log-reader, then assign features to those collectors.
• Telemetry services are separate: Deploying Node Exporter, kube-state-metrics, and OpenCost is controlled under telemetryServices, so existing cluster services are not duplicated silently.
• Metrics are split by concern: clusterMetrics, hostMetrics, and costMetrics are separate features, which makes values files easier to audit.
• Pod log labels are opt-in: The chart no longer promotes every pod label and annotation before filtering them down, reducing wasted Alloy memory in noisy clusters.

Installation

Start with a values file generated from Grafana Cloud, or build one from the official examples:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm install k8s-monitoring grafana/k8s-monitoring \
  --namespace monitoring \
  --create-namespace \
  --values values.yaml

The chart can also be installed from GHCR:

helm install k8s-monitoring \
  oci://ghcr.io/grafana/helm-charts/k8s-monitoring \
  --values values.yaml

GitOps Example

The biggest day-two improvement is map-based configuration. A shared file can define the common destinations, while a cluster-specific file can override one field without redefining the whole list:

destinations:
  prometheus:
    type: prometheus
    url: https://prometheus.example.com/api/v1/write
  loki:
    type: loki
    url: https://loki.example.com/loki/api/v1/push

Then an environment overlay can target a stable path:

helm upgrade k8s-monitoring grafana/k8s-monitoring \
  --values values.yaml \
  --set destinations.prometheus.auth.password="$PROM_REMOTE_WRITE_PASSWORD"

That is a real reliability improvement. A reordered list should never cause a Loki secret to be applied to a Prometheus destination.

Operational Tips

Treat the v4 migration as a configuration review, not just a chart bump. Check which collectors run as DaemonSets, which ones need elevated permissions, and whether Node Exporter or kube-state-metrics already exists in each cluster.

Be conservative with pod log labels. Promote labels like app, team, namespace, and release-version only when they are useful for queries or incident response. High-cardinality labels can make logs expensive and harder to search.

If you are moving from v3, use Grafana's migration tool first, then review the generated values by hand before applying them through GitOps.

Conclusion

Grafana's Kubernetes Monitoring Helm chart v4 is worth a look because it removes common sources of operational drift: positional overrides, hidden collector routing, surprise backing services, and wasteful log label handling. Those are exactly the small chart behaviors that become incident fuel when a platform grows from one cluster to many.

At Akmatori, we help SRE teams build intelligent automation that responds to incidents and manages infrastructure. For GPU-accelerated AI workloads, check out Gcore cloud infrastructure with global edge locations.