We’re at it again, bringing more incremental improvements to Kong Mesh! 

Built on top of Kuma, Kong Mesh brings much-needed simplicity and production-grade tooling. Kong Mesh is built for smooth operations with platform teams in mind, providing security, observability, and traffic control for modern, distributed applications. A single mesh can seamlessly span multiple zones: multiple cloud providers, Kubernetes clusters, and traditional server (VM / bare-metal) environments while offering zero-trust security, multiple isolated mesh support, and global/remote control planes. Konnect Mesh Manager provides a global view across all your Mesh deployments. With Kong Mesh, organizations can deploy with confidence and efficiency, managing mission-critical services reliably at high performance.

Kong Mesh 2.11 delivers several enhancements, including Amazon ECS support with automated Route 53 configuration, the ability to reduce the need for cluster roles when setting up Mesh, Embedded DNS, and experimental support for incremental configuration propagation, and an expansion of the supported policies for MeshHTTPRoute.

Read on to learn more!

ECS Support with automated Route 53 configuration 

While we have supported ECS with Kuma Mesh for a while, customers still have to manually configure the outbounds. This was cumbersome and time-consuming. With Mesh 2.11, you can now configure the control plane to create Route53 domains that will resolve to local addresses for service communication.

Reduction in RBAC scope for Mesh deployments

By default, Kong Mesh observes resources across an entire Kubernetes cluster. In production or shared clusters, this may not be desired as not all namespaces need to be monitored, or your teams do not have the cluster-wide scope to do this.  When deploying Mesh using Helm, you can now specify the namespaces that Mesh is allowed to watch:

This is achieved by taking the kuma-control-plane ClusterRole and binding it to only the allowed namespace via a RoleBinding, greatly reducing the RBAC permissions to allowed namespaces.

Move to Embedded DNS

Historically, we've used CoreDNS for service mapping to VIPs, which was used on all dataplanes. As we look to greatly reduce dataplane resource consumption, we've moved to an Embedded DNS specifically designed for Kuma Mesh. Beyond the reduction in resources needed, this opens up some interesting things we can do in the future to map out service-to-service communication and analytics for your workloads. Stay tuned for where we go with this!

Incremental configuration propagation (Incremental xDS)

By default, Kong Mesh will send the full configuration to the dataplane whenever updates are made in the Mesh. With Incremental configuration, only the differences (delta) of the configuration that has changed are sent to the dataplanes. This reduces CPU and memory utilization and is especially useful as the number of workloads increases.

This is an experimental feature, but can be enabled per dataplane with a Kubernetes annotation, or with an environment variable if using Universal:

Additional policy support for MeshHTTPRoute

MeshHTTPRoute is a routing policy in Kong Mesh that allows you to match and redirect HTTP traffic within the Mesh. This update gives you a much greater level of control over the HTTP protocol, the path, headers, and query parameters.  

We're releasing further policy support for MeshHTTPRoute in the following Mesh policies:

• MeshTimeout: Specify explicit request timeouts for routes
• MeshAccessLog: Capture access logs for traffic that matches a specific route
• MeshRetry: Apply retry logic to specific routes based on HTTP error codes

Next steps

For a deeper dive into a complete list of features, updates, and changes, please refer to the CHANGELOG here.

Want to see Kong Mesh in action? Request a demo or start using Kong Mesh today.

Thank you for your continued support and trust in our product.