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.
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.
VirtualOutbound
.MeshGateway targetRef
support to: MeshHealthCheck
, MeshRetry
and MeshTimeout
.targetRef
policies.And a lot more! Check out the full release notes to see everything in this release.
Up until now, there was only two ways to configure how stats were exposed:
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.
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.
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 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!
Sign up for our Kuma community newsletter to get the most recent updates and product announcements.
Thank you!
You're now signed up for the Kuma newsletter.
Whoops!
Something went wrong! Please try again later.