Featured image for a blog article titled Kuma 2.6 release with targetRef policies as default, dataplane view and MeshMetric.

We’re excited to announce the release of Kuma 2.6, the first release of 2024 packed with exciting changes to help new users.

Upgrading

We strongly suggest upgrading to Kuma 2.6.0. Upgrading is easy through kumactl or Helm. Be sure to carefully read the Upgrade Guide before upgrading Kuma.

Notable features:

  • 🚀 targetRef policies are now default, newcomers do not need to use or know of older policies anymore.
  • 🚀 Standalone mode is getting removed. You can now start a zone without KDS, we also provide an easy path to add a global from an already running zone with federation.
  • 🚀 You can now apply policies to your zone directly. This helps users to use policies without needing to connect to the global control-plane.
  • 🚀 A brand new dataplane GUI which helps you make sense of the dataplane metrics and Envoy configuration.
  • 🚀 A MeshMetric policy providing the flexibility of targetRef policies to your metrics with alpha support for the open telemetry protocol.
  • 🚀 MeshGateway route now can use MeshHTTPRoute and MeshTCPRoute and be targeted by policies.
  • 🚀 Massive documentation revamp to help users get started and easily find what they need.

And a lot more! Check out the full release notes to see everything in this release.

TargetRef policies are now default

We’ve started TargetRef policy in order to provide an easy and powerful way to control where and how policies get applied. After a year of work we are now able to make these as defaults. This means that new user coming to Kuma will not have to deal with 2 types of policies.

For existing users nothing changes, and they still shouldn’t mix and match policies of the same type. Migrating from old to new policies and deprecating old policies for good is planned for release 2.7.0.

Bye bye standalone mode

Originally, when starting to use Kuma, you had to make a choice: whether to use a single zone in standalone mode or multiple zones in multi-zone mode. This was making day 0 harder and migrating from one to the other was complicated.

We are now deprecating standalone mode. Users can start with a single zone and add a global control-plane when they feel the need for it. We wrote a guide and tooling to make the migration as easy as possible.

We hope this will make starting with Kuma easier.

If you are using standalone mode today, migration to zone will be automatic when upgrading.

Applying policies to your zone

When running with a global control-plane (also known as federated zones), you used to only be able to create, modify and delete policies on the global control-plane. This was inconvenient for users mostly using Kubernetes, in 2.6.0 we’re lifting this limitation. Users can now apply policies to their zones and these will be synced to global. They will however, only impact the zones they are applied in. This provides global visibility through federation while maintaining the security and flexibility of allowing your users to access only one Kubernetes cluster.

Dataplane GUI

For a long time users have been able to see the XDS config, stats and clusters of their dataplanes running in a zone from the GUI of the global control-plane. This is powerful but requires pretty deep understanding of Envoy.

We have now provided a new view in the GUI to enable users to make sense of these as you can see in the following screenshots:

The dataplane view The dataplane view when clicking on an outbound

MeshMetric

MeshMetric joins MeshTrace and MeshAccessLog to complete our targetRef based policies for observability.

With this you can easily have different data planes report their metrics differently or elsewhere.

It’s as simple as:

apiVersion: kuma.io/v1alpha1
kind: MeshMetric
metadata:
  name: metrics-default
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  default:
    backends:
      - type: Prometheus
        prometheus:
          port: 5670
          path: "/metrics"

With MeshMetrics you can also dynamically reconfigure data plane metrics to get your instances metrics with Kuma labels easily. Finally, we also provide alpha support for exporting open telemetry metrics which will enable users to use this open standard for all their telemetry.

MeshGatewayRoute deprecation and MeshGateway support for policies

With MeshHTTPRoute and MeshTCPRoute we make MeshGatewayRoute not required anymore. Users can configure their gateways using these policies and also target MeshGateway with its dedicated kind.

For example:

---
type: MeshHTTPRoute
mesh: default
name: api-play-000
spec:
  targetRef:
    kind: MeshGateway
    name: edge-gateway
  to:
    - targetRef:
        kind: Mesh
      rules:
        - matches:
            - path:
                type: PathPrefix
                value: /myservice
          default:
            backendRefs:
              - kind: MeshService
                name: my-service_my-namespace_svc_8080

This makes the builtin gateway an even simpler and powerful way to get traffic inside your Mesh.

Documentation revamp

With all these changes to help users get started, we felt it was needed to rebuild some of our docs to make things easier to find.

We now have:

  • An opinionated getting started guide that is targeted to the most common use-case: Kubernetes
  • A guides section with step by step guides to use different features
  • A use case based section called using Kuma to help users find the feature they are looking for.
  • The policies section now only contains policies in targetRef style but keeps the others in a subsection for reference while they still exist.

As usual we appreciate feedback so let us know what guides you need or what docs needs to be improved in the issues.

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

Get Community Updates

Sign up for our Kuma community newsletter to get the most recent updates and product announcements.