We’re excited to announce the release of Kong Mesh and Kuma 2.2. This new minor release adds some long-awaited enterprise features, more incremental improvements to our UI and policies, and many more minor features and bug fixes.

In order to take advantage of the latest and greatest in service mesh, we strongly suggest upgrading to Kong Mesh 2.2. Upgrading is easy through kumactl or Helm.

Notable features:

Flexibility:

• Added new policy for Global Rate limiting, using a dedicated rate limit service and external redis
• OpenTelemetry support for tracing and access logging
• Added the ability to define MeshProxyPatch policies using JSONPatch, allowing greater power and flexibility to customize underlying Envoy configuration
• Multiple improvements and functionality added to the MeshHTTPRoute policy, including:
  • Cross-zone support
  • Request mirroring
  • Host header rewrites for the MeshGateway
  • Header matching
  • Support for retry predicates and priorities
• Additional options for customizing the pods backing a MeshGatewayInstance deployment
• Upgraded underlying Envoy version to 1.25
• Various other bug fixes and quality-of-life improvements across the product

Scalability:

• New MeshLoadBalancing policy, enabling more granular control of load balancing configuration between services
• Official support for deploying a Universal mode global control plane (Postgres-backed) to a Kubernetes cluster for better availability and resilience characteristics

Security:

• Ability to provide a public key for offline token signing and validation
• Composable Open Policy Agent (OPA) policies, now allowing multiple OPA policies to be applied to the same services
• Improved RBAC views in the UI

For more details, reference the Kong Mesh Changelog.

Global Rate Limiting

We’ve had the ability to configure local rate limiting in Kong Mesh for some time, through the use of the RateLimit policy. However, this was only able to affect limits to a single instance of the service as the limit was applied on the inbound listener. In 2.2, we’re introducing the capability to add a global rate limit to a service, allowing users to restrict the calls to the combined instances of a service.

This new capability adds a new global-rate-limiting service that is deployed to the environment (can be auto-installed with Helm on Kubernetes, or manually in Universal VM mode) with an added dependency on an external Redis installation.

Figure 1: Global Rate Limiting architecture

Head over to the docs to read more about deploying and configuring this new Global Rate Limiting capability today.

OpenTelemetry Support

We’re really excited to announce that in 2.2 we’ve released the ability to use an OpenTelemetry collector as a target for both access logs and traces within Kong Mesh and Kuma. Huge shoutout to our community who contributed this functionality upstream!

Our support for OTEL means that in both the MeshAccessLog and MeshTrace policies, it’s now possible to specify an openTelemetry type backend:

apiVersion: kuma.io/v1alpha1
kind: MeshAccessLog
metadata:
  name: default
  namespace: kong-mesh-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  from:
    - targetRef:
        kind: Mesh
      default:
        backends:
          - file:
              path: /tmp/access.log
              format:
                plain: '[%START_TIME%]'
          - openTelemetry:
              endpoint: otel-collector:4317
              attributes:
                - key: "start_time"
                  value: "%START_TIME%"

Figure 2 : Logging to multiple backends, demonstrating the new openTelemetry backend

The OTEL collector is a great way to collect log, trace, and metrics data and translate and send that to any external observability vendor tooling.

Head over to the docs to check out how to use the new OpenTelemetry backend with both MeshAccessLog and MeshTrace policies.

Kubernetes Deployments with Postgres Storage

Kong Mesh and Kuma historically supported two different deployment modes, Kubernetes and Universal (VM / non-containerized). In the former, we use etcd at the persistence layer for configuration in the form of Kubernetes CRDs. In the latter, we utilize an external Postgres database to persist all of the policy and configuration objects. If Kong Mesh and Kuma were deployed in a cloud provider’s Kubernetes distro, this would likely mean that we were running with more limited HA capabilities as clusters can typically only span multiple availability zones within a region. If an entire region were to experience downtime, the global control plane would also be degraded.

In 2.2, we’re adding built-in support for a combination of the above modes that we’re calling ‘Universal on K8s’. It allows users to deploy Kong Mesh and Kuma into Kubernetes but pointing to an external Postgres datastore (rather than making use of CRDs), allowing them to span a single deployment across multiple regions, increasing resiliency.

This is a model of deployment we use internally here at Kong to power our Kong Konnect platform, and we’re formalizing support for it so it can be utilized by our users in the form of additional Helm chart options and supporting documentation.

Figure 3: ‘Universal on K8s’ mode, with Postgres storage

New RBAC UI Views

As part of our ongoing improvements to our Kong Mesh UI, we’ve simplified our navigation sidebar (and will be making further changes in coming releases). We’ve also streamlined and enhanced our Role-Based Access Control section to make it easier for users to see the roles and role bindings that exist in the environment and which permissions each role has access to.

Figure 4: New UI RBAC view, streamlined with easier access to relevant information

We’re excited about how the UI effort is looking, and many more UI improvements are coming in the next few releases, so stay tuned!

Get in touch with Kong to learn more about Kong Mesh and how to build an enterprise service mesh. You can also download Kong Mesh and get started for free.