Kuma 0.6.0 Released With Hybrid Universal Support for Service Mesh and CNCF Donation

Jun 30, 2020 / 7 min read

We are happy to announce the much-anticipated Kuma 0.6 release! This new release ships with major improvements, especially when it comes to supporting service meshes that can span across multiple clouds, multiple Kubernetes clusters and hybrid platforms (Kubernetes + VMs) in enterprise environments.

Kuma has also been donated to the CNCF as a Sandbox project: the first Envoy-based service mesh to ever be donated to the foundation. Let’s unwrap these announcements.

Hybrid Universal

When Kuma was first released in September 2019, we introduced a service mesh with universal support for VM-based workloads in addition to native Kubernetes deployments. We learned by working very closely with a few early enterprise adopters of service mesh — like Telus in Canada — that a service mesh really is the most valuable the bigger it is. But in enterprise environments, that meant not only supporting Kubernetes workloads natively but also providing a first-class integration for VM-based workloads that are already running within the organization. That’s why Kuma has always shipped with two modes: Kubernetes and Universal. The former is entirely configurable with Kubernetes CRDs, and the latter supports VM-based workloads on both the control plane and the data plane via declarative configuration and a RESTful API.

With Kuma 0.6, we are now extending the original DNA of Kuma with support for hybrid universal workloads, which allows not only the creation of different service meshes across both Kubernetes and VM workloads but also allows for the support of them together within the same mesh. This, combined with Kuma’s multi-mesh support, allows users to run one control plane of Kuma with as many service meshes as they need that could be running on virtually every platform within the organization.

The traditional deployment of Kuma — with one control plane only — is still supported for simpler environments and forever will be.

Among the new features that enable Hybrid Universal: Global/remote control planes, service discovery and Kuma ingress for cross-zone communication

By introducing a “global control plane” for global service mesh policy configuration and as many “remote control planes” as the zones that we want to support, we also introduce a more scalable service mesh that can rely on distributed control planes to scale with a large number of data planes. A zone could be a VPC in a cloud provider, a Kubernetes cluster or a data center, and it can support both container-based workloads on Kubernetes as well as VM-based workloads together within the same service mesh.

The global control plane communicates with the remote ones via xDS that is now being used not only to communicate with the Envoy-based data planes but also across distributed control planes, making the entire architecture very Envoy-native.

Automatic Service Discovery + Kuma Ingress

As usual, it is possible to create many “meshes” within the same Kuma cluster — which can span across multiple zones — simplifying the operational costs of running a service mesh for the entire organization. But this leaves us with a very important problem to solve: as a developer building a service that wants to consume another service, I may not know where the destination service is being hosted and that service could be transferred to other zones anyway in the future.

Introducing Kuma’s “.mesh” DNS zone and Kuma ingresses. Kuma simplifies cross zone communication by allowing users to create an Envoy-based ingress deployment on both Kubernetes and VMs, as well as by introducing a service discovery functionality that relies on a new custom DNS zone for all of our services (by default “.mesh”). This is how it works:

A service (ie: “backend”) wants to consume another service (ie: “redis”).
The “backend” service may not know where the “redis” service is running: perhaps it’s in another cloud, or cluster, within the same Kuma mesh.
In order to consume “redis,” the “backend” service can now leverage the new functionality in Kuma 0.6.
The “backend” will make its requests to “redis.mesh:80” (always port 80). Kuma will take it from there and re-route the request to wherever “redis” is being hosted on the correct port, transparently from the originating “backend” service.
If “redis” is being hosted in another Kuma zone, Kuma will automatically route the request through the ingress for that zone before forwarding it to the “redis” service.
With mTLS, everything is encrypted end-to-end, therefore enforcing security for all traffic going through the mesh, including the ingresses.

You can learn more about the new functionality in Kuma 0.6 from the official documentation, and you can always join us on Slack if you have questions!

Kuma Is Now a CNCF Sandbox Project!

Kuma has been accepted by CNCF as a Sandbox project in the foundation! This makes Kuma the first Envoy-based service mesh to be donated to the foundation, ever. We will be spending the next couple of weeks to transition the project to its new home according to the CNCF guidelines, including transferring the Kuma trademark to the foundation.

With Kuma, the broader community can now adopt a neutral Envoy-based service mesh built with simplicity and portability in mind. We encourage everybody to join us on our bi-weekly calls to tell us about new requirements and use cases as well as contribute overall to make Kuma a better project! We are also looking for new maintainers in order to keep up with the remarkable velocity and momentum that we have achieved so far.

Notable Improvements in 0.6

New Hybrid Universal mode to build distributed service meshes
Introducing Global/Remote control planes
Introducing a new DNS resolver for Service Discovery
Introducing a new Kuma Ingress for cross-zone communication
Introducing the new resources in the GUI
Several bug fixes and improvements

For a complete list of features and updates, take a look at the full changelog.

Community Calls + Slack

Join us on our community channels 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, and we welcome everybody to contribute and ask questions.

The next community call will be hosted on July 8 at 8:30am PDT. Also don’t forget to follow Kuma on Twitter!

Upgrading

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