Kubernetes Monitoring Helm chart 2.0: a simpler, more predictable experience

The Kubernetes Monitoring Helm chart 2.0 is here, and it comes with some exciting changes to improve your experience collecting observability data.

The Kubernetes Monitoring Helm chart makes it easy to start gathering telemetry data from your Kubernetes clusters. With one deployment, you can capture all of the metrics, logs, traces, and profiles from your cluster and the applications running on it!

The Helm chart utilizes Grafana Alloy, our open source distribution of the OpenTelemetry Collector, for its powerful ability to collect data, as well as several proven open source utilities like Node Exporter, OpenCost, and Kepler.

Let’s take a look at all the exciting updates in version 2.0.

What’s new in version 2.0

There are many exciting changes in version 2.0 that will make your configurations simpler and more predictable. All of these changes were inspired by the feedback and comments we have heard from our amazing community.

Here are a few of the most notable changes.

User-focused feature design

With version 2.0, you don’t have to know the underlying observability technologies, you just indicate what you want to observe. Each of the methods for gathering telemetry data has been reorganized into their own features.

Here, and in the remaining sections of this post, I’ll highlight some examples of how much easier it is to use version 2.0 compared to previous versions.

metrics:
  kubelet:
    enabled: true
  cadvisor:
    enabled: true
  kube-state-metrics:
    enabled: true
  node-exporter:
    enabled: true
  windows-exporter:
    enabled: true
  cost:
    enabled: true
prometheus-windows-exporter:
  enabled: true

clusterMetrics:
  enabled: true

Multiple destinations

Version 2.0 allows you to define as many destinations for your telemetry data as you want. This means that you can send metrics to multiple endpoints, or forward your traces to two different targets. There are many more flexible options for defining destinations, and it even opens the possibility for more destination types.

externalServices:
  # All metrics have to go here
  prometheus:
    …

destinations:
  - name: localPrometheus
    type: prometheus
    …
  - name: grafanaCloudPrometheus
    type: prometheus
    …

This also means that you can send all of your metrics, logs, and traces to a single OpenTelemetry-compatible backend that is capable of receiving these signals.

externalServices:
  prometheus:
    protocol: otlp
    …
  loki:
    protocol: otlp
    …
  tempo:
    …

destinations:
  - name: singleBackend
    type: otlp
    metrics: {enabled: true}
    logs:    {enabled: true}
    traces:  {enabled: true}
    …

Built-in integrations

Adding configuration to capture telemetry data for popular services used to be cumbersome, and it involved lots of copying and pasting. Now, certain service integrations are built-in to the Helm chart. This means you get the benefit of pre-defined Alloy configurations with the benefits of validation, easy upgrades, and inter-feature compatibility.

2.0 is shipping with these integrations:

• Grafana
• Grafana Alloy
• Grafana Loki
• Grafana Mimir
• cert-manager
• etcd
• MySQL

We plan to add more integrations in the future, so please let us know which ones you’d love to see in upcoming versions!

extraConfig: |
  discovery.relabel "cert_manager" {
    …
  }
  prometheus.scrape "cert_manager" { 
    …
  }

integrations:
  cert-manager:
    instances:
      - name: cert-manager
        …

Fully compatible with Fleet Management

If you want to manage your Alloy configs directly from your Grafana Cloud stack, Fleet Management, which enables you to manage collector deployments at scale, is a fantastic solution. With version 2.0 of the Kubernetes Monitoring Helm chart, it’s simple to add your Alloy instances to your remotely managed fleet of collectors!

extraConfig: |
  remotecfg {
    // Raw alloy component definition
    …
  }

alloy-metrics:
  remoteConfig:
    enabled: true
    url: https://fleet-management.grafana.net
    auth:
      type: basic
      username: 123456
      password: <my access policy token>

How to migrate to 2.0

Even with all of these changes, we’re doing what we can to make migration as simple as possible. Most of v1’s settings will map directly to a setting in v2, and we have created a migration guide to help show how to do that. We are also building a migration utility that should be able to take your v1 values.yaml file and return a valid v2 values.yaml file.

Share your feedback

We love to hear from you! If you are using this Helm chart, tell us what you think. We drive development on feedback and contributions. Find us in the Grafana public Slack in the #kubernetes channel, or attend one of our k8s-monitoring Helm chart office hours.

Grafana Cloud is the easiest way to get started with metrics, logs, traces, dashboards, and more. We have a generous forever-free tier and plans for every use case. Sign up for free now!