Today we are happy to announce the release of Kubewarden 1.8.0! 🎉🥳

This is a small release, focused on OpenTelemetry.

The OpenTelemetry Protocol (OTLP) got its first 1.0.0 version in July 2023; several libraries got their first 1.0.0 release, such as the Go metric SDK or the .NET Automatic Instrumentation.

Still, the OpenTelemetry stack is not yet stable, and unannounced backwards-incompatible changes still happen. You can have a look at the status of each of their libraries and protocols here.

For Kubewarden, this means we should expect more users to configure and fine tune the deployment to fit their stacks.

Changes

With 1.8.0, the Kubewarden Controller now separately reconciles the configuration of both tracing and metrics for Policy Server instances. In the past, enabling metrics in Kubewarden meant enabling both, and now users can decide to enable each separately, as we have realized from the requests raised by the community.

We have made the concious decision to make this a breaking change in the helm chart values.yaml, which is uncommon. We think it simplifies the adoption of OTLP changes in the future.

In addition, since v0.85.0 OpenTelemetry Collector no longer includes exporters for the native Jaeger format. This change was prompted because Jaeger has support for OTLP. See the announcement here.

Now the OpenTelemetryCollector resource created by the helm chart is configured to use exporters.otlp/jaeger instead of exporters.jaeger. For the user, this means a change in the port of the endpoint, from 14250 (native Jaeger format) to 4317 (OTLP/jaeger).

The change is the following:

# values.yaml
# open-telemetry options
telemetry:
- enabled: False
  metrics:
+   enabled: False
    port: 8080
  tracing:
+   enabled: False
    jaeger: {}
    # OTLP/Jaeger endpoint to send traces to
-    # endpoint: "all-in-one-collector.jaeger.svc.cluster.local:14250"
+    # endpoint: "all-in-one-collector.jaeger.svc.cluster.local:4317"

Example

Up until 1.7.x inclusive we had:

---
# values.yaml
# Up until 1.7.x inclusive
telemetry:
  enabled: True
  metrics:
    port: 8080
  tracing:
    jaeger:
      endpoint: "my-open-telemetry-collector.jaeger.svc.cluster.local:14250"
      tls:
        insecure: true

Starting with 1.8.0 we have:

---
# values.yaml
# Starting with 1.8.0:
telemetry:
  metrics:
    enabled: True
    port: 8080
  tracing:
    enabled: True
    jaeger:
      endpoint: "my-open-telemetry-collector.jaeger.svc.cluster.local:4317"
      tls:
        insecure: true

Configuring OpenTelemetry manually

As always, users may still configure metrics and/or tracing support themselves, as desired. For example in case that they want only some of the Kubewarden workloads with telemetry, or more exotic configurations.

This would mean leaving the default values.yaml, and performing the following by hand:

1. Instantiating their own OpenTelemetryCollector.
2. Making sure the OTLP collector can consume data from Kubewarden workloads. For example by using a sidecar, and adding the “sidecar.opentelemetry.io/inject”: “true” annotations to the kubewarden-controller and PolicyServers.
3. Configuring kubewarden-controller and PolicyServers binaries to enable metrics and tracing via their env vars.

See you around!

As always, we are curious of what features you would like next and how you are enjoying Kubewarden. Reach out to us on slack or join our monthly community meeting to talk more about Kubewarden!