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
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]
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:
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.
[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!
Kong Mesh 2.13 delivers full support for Mesh Identity for Kubernetes and Universal mode. Plus, it's been designated as a Long Term Support release, with support for a total of 2 years. But first, what's Kong Mesh for the uninitiated? Built on top
In today’s interconnected and dynamic world of microservices, ensuring optimal traffic management and protection against malicious attacks are critical. Rate limiting , a popular mechanism for controlling request flow, gets more effortless with the
We’re excited to announce the release of Kong Mesh and Kuma 2.1! In this release, we’re shipping the full suite of new and improved policies announced (and started) in 2.0. Additionally, we’re launching some more great UX improvements in the UI and a
Today we’re excited to announce the release of Kong Mesh and Kuma 2.0. With this new major release, we’re announcing the first availability of our next-generation policies, in addition to new eBPF capabilities. 2.0 is also significant as we have
We are happy to announce the release of Kong Mesh 1.9 and Kuma 1.8! This release is packed with features and improvements such as observability for builtin Gateway, a complete rewrite of the CNI and projected service account tokens support. In order
We’re excited to announce the latest release for both Kuma and Kong Mesh. This cycle, we focused on simplifying enterprise-wide mesh deployments. We strongly suggest upgrading, in order to take advantage of the latest and greatest when it comes to s
We are happy to announce the first release for both Kong Mesh and Kuma in 2022, which is packed with features and improvements, including substantial performance improvements when running at scale. We strongly suggest to upgrade, in order to take ad