Featured image for a blog article titled Kuma 2.4 release with sidecar lifecycle, metrics TLS and multi-zone improvements.

We’re excited to announce the release of Kuma 2.4, a new minor release improves cross zone routing, adds a new alternative metrics TLS setup and improves observability further.

Upgrading

We strongly suggest upgrading to Kuma 2.4.0. Upgrading is easy through kumactl or Helm. Be sure to carefully read the Upgrade Guide before upgrading Kuma.

Notable features:

  • 🚀 Support for user provided certificates to be used to scrape from prometheus securely.
  • 🚀 Add multi-zone support for VirtualOutbound.
  • 🚀 Wait for sidecar to be ready before starting the app.
  • 🚀 Add MeshGateway targetRef support to: MeshHealthCheck, MeshRetry and MeshTimeout.
  • 🚀 Many improvements to the GUI.
  • 🚀 Improved kubectl support with targetRef policies.
  • 🚀 Upgrade to Envoy 1.27.

And a lot more! Check out the full release notes to see everything in this release.

User provided metrics certificate.

Up until now, there was only two ways to configure how stats were exposed:

  1. No security
  2. With the mesh mTLS

The second option requires the prometheus instance to run inside the mesh, which can be difficult to put in place when the Prometheus instances are shared with applications outside the mesh.

To address this, we are adding support for user provided certificates. This allows you to use your own certificates to secure the traffic between the Prometheus instance and the Kuma mesh.

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  metrics:
    enabledBackend: prometheus-1
    backends:
    - name: prometheus-1
      type: prometheus
      conf:
        tls:
          mode: activeMTLSBackend
        port: 5670
        path: /metrics
        tags: # tags that can be referred in Traffic Permission when metrics are secured by mTLS  
          kuma.io/service: dataplane-metrics

You can then set the environment variables KUMA_DATAPLANE_RUNTIME_METRICS_CERT_PATH and KUMA_DATAPLANE_RUNTIME_METRICS_KEY_PATH when a dataplane starts and have them point to the certificate you want to use.

In Kubernetes you’ll container-patches.

Note that as part of this change we’re deprecating skipMTLS in favour of tls.mode. While you can still use skipMTLS we’ll remove this syntax in a future release of Kuma.

Cross-Zone routing improvements

The powerfulness of cross zone routing in Kuma is one of the reason that it stands out as a service mesh. Unfortunately up until now VirtualOutbound were not supported cross-zone.

Kuma 2.4.0 adds support for cross-zone routing for VirtualOutbounds. This means that you can now securely access services in remote zones, such as a Kafka cluster.

Wait for sidecar to be ready before starting the app

In Kubernetes, the sidecar and the application containers start in parallel. This could lead to problems if the network was not available when the sidecar started.

Kuma 2.4.0 allows you to configure the sidecar to wait until it is ready before starting the application container. This ensures that the application container has access to the network when it starts.

To do so, use the control plane config runtime.kubernetes.injector.sidecar.waitForDataplaneReady=true for the application container to not start before the sidecar is ready. You can also restrict this to a pod by using the annotation: kuma.io/wait-for-dataplane-ready.

Join the community!

Join us on our community channels, including official Slack chat, to learn more about Kuma. The community channels are useful for getting up and running with Kuma, as well as for learning how to contribute to and discuss the project roadmap. Kuma is a CNCF Sandbox project: neutral, open and inclusive.

The community call is hosted on the second Wednesday of every Month at 8:30am PDT. And don’t forget to follow Kuma on Twitter and star it on GitHub!

Get Community Updates

Sign up for our Kuma community newsletter to get the most recent updates and product announcements.