Kong Mesh & Kuma 2.2 Released with Global Rate Limiting, OpenTelemetry, and More
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
- 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
- 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
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.
[caption id="attachment_48017" align="aligncenter" width="1024"]
Figure 1: Global Rate Limiting architecture[/caption]
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:
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.
[caption id="attachment_48018" align="aligncenter" width="1024"]
Figure 3: ‘Universal on K8s’ mode, with Postgres storage[/caption]
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.[caption id="attachment_48019" align="aligncenter" width="1024"]
Figure 4: New UI RBAC view, streamlined with easier access to relevant information[/caption]
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.