Kuma 1.6.0 GA Released With Kubernetes Gateway API support, ZoneEgress improvements, a new and improved transparent-proxy and more.

We are happy to announce Kuma’s latest release, which is packed with features and improvements.

We strongly suggest upgrading, in order to take advantage of the latest and greatest when it comes to service mesh.

Notable Features

• 🚀 We provide a preview of Kubernetes Gateway API support for our builtin gateway. This makes it easier than to provide a gateway to lead traffic through your mesh.
• 🚀 Full support for the “inspect API” on builtin gateway resources. This enables users to see which policies impact which gateway routes.
• 🚀 ZoneEgress received many improvements like: support for Standalone, locality aware routing on external services and support for FaultInjection and RateLimit policies on external services.
• 🚀 A preview of the completely rewritten transparent proxy, this aims to make transparent proxy more stable and provide us with pathways for further innovation.
• Many improvements to the Helm charts like: exposing the CP with an ingress, providing resource limits to components, and customizing image tags and security context.
• A new metric to see how long configuration changes take to propagate to data plane proxies.

And a lot more! The full changelog is available here.

Kubernetes Gateway API (experimental)

The gateway API kubernetes sig is gaining traction and quickly converging to be a flexible successor to Ingress in Kubernetes. Since Kuma 1.5.0 we support a builtin Envoy Gateway fully configurable with Kuma policies. It made sense for us to make the Kubernetes story complete by also providing Gateway API support.

Gateway API is currently experimental and is enabled with the kuma-cp flag --experimental-gatewayapi and will also need the Gateway to be enabled with --experimental-meshgateway.

Check the Gateway API docs for more information.

Transparent-proxy rewrite (experimental)

The current transparent proxy implementation presents both a maintenance burden and a limit on our options for innovation. We have big plans for transparent proxy including some features using cutting edge network and kernel technologies. As a first step in this effort we’ve completely rewritten the iptables transparent proxy rules.

We’re releasing this rewrite as an experimental feature in version 1.6.0. It can be enabled with kumactl install transparent-proxy --experimental-transparent-proxy-engine. Please take it for a run in dev (this is not ready for production yet) and let us know of any issues!

ZoneEgress improvements

In Kuma 1.5.0 zone egress was released, it enables routing all traffic external to the mesh through a dedicated set of proxies. This was a very big step towards our goal to provide best in class support for external services.

In this release we improved ZoneEgress even more with the following features:

You now need to opt-in your mesh to route traffic through the ZoneEgress. Previously zone egress routing would be dependent on the presence of a zone egress instance, which would cause data plane proxies to be reconfigured if zone egresses where shutdown. With this feature, routing is not dependent on the state of your zone egress instances.

When using external service you can now force the traffic to exit your mesh in a specific zone. This is useful if you want to leverage all the features Kuma provides until you are very close to the service that is outside the mesh. To make this happen simply add a kuma.io/zone tag to your external service definition. Check the external service docs for more details.

One of the benefit of ZoneEgress is routing all external service traffic through a set of instances, this has the benefit of providing higher control on the network traffic and make external service closer to regular data planes. In Kuma 1.6.0 you can do all of this in Standalone mode, too!

To learn more about ZoneEgress check out the docs.

Configuration propagation metric

When operating a service mesh one thing you need to be aware of is how long it takes for your data plane proxies to receive configuration changes.

This is now possible with the metric: xds_delivery.

For example, we see the impact of reachableServices thanks to this metric. In the graph below we first deploy 50 services with 3 instances first without reachableServices and then do the same thing with reachableServices.

Thanks to this new metric, you can see that annotating your instances with kuma.io/transparent-proxying-reachable-services significantly improve configuration delivery time.

A chart to track this metric has been added to the control-plane dashboard.

Kuma 1.5.1

We are also releasing a patch release of Kuma 1.5.x with some critical bug fixes. Make sure to check the CHANGELOG.

Join us on the community call!

Join us on our community channels, including our 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 next community call will be hosted on April 13th at 8:30am PDT. And don’t forget to follow Kuma on Twitter and star it on GitHub!

Upgrading

Be sure to carefully read the Upgrade Guide before upgrading Kuma.