We are happy to announce Kuma's first release of 2022, which is packed with features and improvements, including substantial performance improvements when running at scale.
We strongly suggest to upgrade, in order to take advantage of the latest and greatest when it comes to service mesh.
builtingateway mode in addition to
delegatedmode. Kuma now ships with an Envoy-based gateway implementation to expose services from within the service mesh to the outside world - or to other meshes - using an Envoy based ingress.
Mesh(in addition to the bottom-up membership mode that is already supported, where a DPP can choose what
Meshit belongs to).
And a lot more! The full changelog is available here (opens new window).
Kuma 1.5 ships with new troubleshooting capabilities in the GUI and CLI
Kuma is a multi-zone service mesh and since the beginning it supported the concept of
Zone Ingress to allow traffic generated from a zone to enter another zone through a centralized ingress resource. Traffic that is coming outside of Kuma can enter the
Gateway data plane proxies.
With Kuma 1.5, we have finally introduced a new Zone Egress resource, to channel traffic exiting a zone through a centralized egress component. Prior to this capability, the only egress functionality that Kuma supported was for egress traffic to exit the zone directly from the data plane proxies (which is still supported if we prefer the operational simplicity of not having to manage an additional component).
This gives us plenty of options when it comes to managing our ingress and egress traffic from within our Kuma zones.
This release of Kuma introduces a new builtin Gateway data plane proxy (technical preview), that can be used to expose mesh services to the outside world via an Envoy proxy. The new
builtin gateway works across Kubernetes and VMs (like every other feature of Kuma). Before we release this feature as GA in the next release, this new gateway will also natively support the new Kubernetes Gateway API specification, the successor of the older
This also means that starting from today, Kuma supports two gateway modes:
Delegated gateways have been supported for a long time, and they can be used to expose services to the outside world by delegating the capability to a 3rd party API Gateway, like Kong Gateway. This gives us plenty of options when it comes to exposing our services from within a
builtinmode], which has the benefit of not requiring a 3rd party solution.
The builtin gateway is currently experimental and is enabled with the kuma-cp flag
--experimental-meshgateway or the environment variable
We always put lots of effort into improving the performance of Kuma to better sustain large service mesh deployments. On this release, we have significantly refactored our memory management capabilities and - by doing so - decreased memory consumption by 90%.
Below, you can observe the differences in memory consumption between Kuma 1.4.1 and the new 1.5.0, when new services are being added.
Performance is a key focus area of Kuma, and this is one of many performance improvements that we have shipped into the project over the past few months, in order to make Kuma easier than ever to scale in production environments.
Join us on our community channels (opens new window) to learn more about Kuma, including our official Slack chat. The community channels are useful to get up and running with Kuma, as well as to learn 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 (opens new window) before upgrading Kuma.
Sign up for our Kuma community newsletter to get the most recent updates and product announcements.