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.
RateLimit policies on external services.
And a lot more! The full changelog is available here.
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
--experimental-gatewayapi and will also need the Gateway to be enabled with
Check the Gateway API docs for more information.
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!
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
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.
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:
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
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.
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 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.
Be sure to carefully read the Upgrade Guide before upgrading Kuma.
Sign up for our Kuma community newsletter to get the most recent updates and product announcements.
You're now signed up for the Kuma newsletter.
Something went wrong! Please try again later.