We’re excited to announce the biggest release of Kuma since 2.0! In this release we offer a complete beta release of our service rework and namespaced policies.

Notable features

In Kuma 2.9.x we’ve focused on 3 main areas:

• MeshTLS which provides a more granular way to roll out strict Mutual TLS.
• New resources MeshService and MeshMultiZoneService which provide a more intuitive and powerful way to manage services in your mesh.
• A complete rework of our destination policy attachment which works with the new services.
• Introduction of producer and consumer policies, enabling more flexibility for Kubernetes users.

This set of features greatly simplifies Kuma’s user experience, by making it clearer how services exist and by attaching policies to specific resources. These changes are also fully integrated with our GUI thus making things easier to understand and troubleshoot.

This release marks an important step in simplifying the Kuma user experience, empowering both key user roles: mesh administrators and service owners.

Feel free to check our release notes for the full list of changes.

New TLS policy

Mutual TLS is one of the most common use cases in Kuma. This is because it’s the base on which you can build fully secured environments. The most common way to roll out mutual TLS is by first running services in permissive mode. In this mode, while the mesh will verify client certificates, it will still allow unsecured connection. You can then progressively remove unsecure connections by moving clients inside the mesh and once it’s complete switch to strict mode.

This has been long supported in Kuma. However, it was done at the mesh wide level which created an all or nothing setup. In 2.9.x we’ve introduced a policy to apply this to only some data planes, thus enabling easier progressive adoption of strong security.

To check how to do this please checkout the MeshTLS guide.

This feature is part of a larger effort to address challenges users may be facing rolling out a service mesh in their production environment. We are always looking for more input on these challenges, if you are willing to share please feel free to reach out to us on slack.

New service resources

From the beginning, Kuma has always implicitly defined services from its workloads. While this was convenient for getting started, it came with the following shortcomings:

• It wasn’t possible to have multiple services fronting the same port of a data plane, which is required for blue-green deployment for example.
• Creating subsets of services was impossible in policies which made things hard to understand, observe and compose across multiple policies.
• The opacity between multi-zone and single zone services complicated things. We believe that while multi-zone services are useful, the real necessity is cross-zone communication. Making all services multi-zone by default mode a lot of simple cross-zone setups harder than they should have been.
• You may want to manage traffic going across zones differently from traffic that stays inside a zone.

With MeshService we now have a dedicated service object which selects a set of data planes to send traffic to. This MeshService is defined in both policies and Envoy configuration, making it very easy to understand and observe. The resources can be labeled which enables policies that apply to whole subset of your services.

MeshService is cross-zone by default but not multi-zone. This means that each MeshService can only be present in a single zone at time. However, it can be accessed by other zones thanks to our cross-zone communication setup. If you want a service to be multi-zone you need to create a MeshMultizoneService which will group multiple services inside the same resource and Envoy cluster.

Along with MeshService we’re rolling out new ways to address services, this means that we’re parting with the .mesh addresses that were used in the past. We will now use addresses that by default are zone and service type specific. This is mostly to make the getting started experience easier. This is configurable with HostnameGenerator

MeshService is currently disabled by default and there’s a migration procedure if you want to use it. Because the use cases and usability of Kuma is greatly improved we’ve updated our quickstart to use MeshService. If you want to look at the migration check out our migrating to mesh service doc.

We’re also working on a comprehensive guide to help users better understand the value and use-cases for MeshService and MeshMultizoneService.

Namespaced policies and policy attachment rework for outbound policies

One of the things that Kuma excels out at is its policy system. Its goal is to be as powerful and expressive as possible and to respond to both of our user’s personas: the mesh operator and the service owner.

One part of our vision for policies is to “make policies as easy as horizontal pod autoscaler”. This means each service owner should be able to just add their policies where they define their services and workloads, like in a helm chart for example. Up until now this was problematic because policies needed to be applied to the mesh system namespace. This is no longer the case with namespaced policies where policies can be created in any Kubernetes namespace.

This update introduces two types of policies:

1. Policies impacting clients of a service: These policies allow service owners to add configurations that affect client behavior, regardless of where those clients are running. Since service owners understand their services best, they have full control over these settings. These policies must be defined where the service is defined.
2. Policies limited to owned data planes: These policies are restricted to the specific scope in which they’re defined-whether that’s a namespace, zone, or cluster. This ensures that the policies only impact data planes within the owner’s domain.

As most of our features you can follow the guide getting started with producer/consumer policies.

Improving how we work with our docs

In recent versions we started adding guides to help users getting started with different features. We’ve had good feedback about this so we’re going to systematically add guides for all new Kuma features. We will also review existing guides as part of our qualification process to keep things as up to date and accurate as possible.

Upgrading

We strongly suggest upgrading to Kuma 2.9.0. Upgrading is easy through kumactl or Helm.

Be sure to carefully read the upgrade guide and the version specific upgrade notes before upgrading Kuma.

Join the community

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:30 AM PDT. And don’t forget to follow Kuma on Twitter and star it on GitHub!