We’re excited to announce the release of [Kong Mesh](https://konghq.com/products/service-mesh-platform)Kong Mesh and [Kuma](https://kuma.io/)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 host of smaller fixes.

In order to take advantage of the latest and greatest in service mesh, we strongly suggest [upgrading to Kong Mesh 2.1](https://docs.konghq.com/mesh/changelog/#210)upgrading to Kong Mesh 2.1. Upgrading is simple through kumactl or Helm.

Notable features:

• Completed implementation of all next-generation policies, adding:
  • MeshHTTPRoute
  • MeshCircuitBreaker
  • MeshFaultInjection
  • MeshHealthCheck
  • MeshOPA
  • MeshProxyPatch
  • MeshRateLimit
  • MeshRetry
  • MeshTimeout
• Added support for header absence matching in traffic routes
• Ability to filter admin API output
• Added gateway view to the UI
• Ability to filter by tags and types in the UI
• Ability to configure ports in eBPF mode
• Various other bug fixes and quality-of-life improvements across the product

Full Next-Generation Policy Suite

As a refresher, the new selectors use a targetRef system (inspired by GatewayAPI) to select which meshes, services, data plane proxies, etc. are targeted by specific policies. Multiple rules can be specified in the same policy (as supported today) or many different policies can be created targeting different subsets. With the new policy system in Mesh 2.1 the policies will be merged together in the correct precedence rules before calculating and pushing the configuration out to the Envoy dataplane.

If you want to read more about the reasoning behind switching and the design of this new policy matching system, check out the blog post [Flexible Policy Match in Kuma 2.0](https://konghq.com/blog/flexible-policy-match-in-kuma-2-0)Flexible Policy Match in Kuma 2.0 by our Mesh Engineering Manager [Charly](https://mobile.twitter.com/moltch)Charly.

Below is an example of a new MeshHTTPRoute using targetRef selectors:

apiVersion: kuma.io/v1alpha1
kind: MeshHTTPRoute
metadata:
 name: http-route-1
 namespace: kuma-system
 labels:
   kuma.io/mesh: default
spec:
 targetRef:
   kind: MeshService
   name: frontend_kuma-demo_svc_8080
 to:
   - targetRef:
       kind: MeshService
       name: backend_kuma-demo_svc_3001
     rules:
       - matches:
           - path:
               type: Prefix
               value: /api
         default:
           backendRefs:
             - kind: MeshServiceSubset
               name: backend_kuma-demo_svc_3001
               tags:
                 version: "1.0"
               weight: 90
             - kind: MeshServiceSubset
               name: backend_kuma-demo_svc_3001
               tags:
                 version: "2.0"
               weight: 10

Figure 1 : Example of a next-gen MeshHTTPRoute policy

While slightly more verbose than the previous TrafficRoute policy, this new selector scheme allows more flexible and granular control. Additionally, we’ll now take care of merging (according to the [documented precedence rules](https://kuma.io/docs/2.1.x/policies/meshhttproute/#merging)documented precedence rules) policies that target the same data plane proxies, rather than only choosing the most specific policy (as was the case pre v2.0).

In 2.0 we implemented 3 policies using this new matching system:

• MeshTrafficPermission
• MeshAccessLog
• MeshTrafficTrace

• MeshHTTPRoute (partially replaces TrafficRoute)
• MeshCircuitBreaker
• MeshFaultInjection
• MeshHealthCheck
• MeshOPA
• MeshProxyPatch (replaces ProxyTemplate)
• MeshRateLimit
• MeshRetry
• MeshTimeout

Continued UI & UX Improvements

[caption id="attachment_47545" align="aligncenter" width="1024"] Figure 2: New, cleaner navigation menu[/caption]

Having quick access to the visualization of the policies is critical for managing complex applications. In order to simplify that all of the Kong Mesh policies have been collapsed into a single Policies screen and are now accessible via a dropdown when navigating through them, as shown in Figure 2.

[caption id="attachment_47546" align="aligncenter" width="1024"] Figure 3: Policies are now listed in a dropdown[/caption]

Furthering the simplification of management, we’ve also added the ability to filter in the UI via a number of metadata fields (e.g., name, tag). These can be combined to provide very specific views of your data planes and services:

[caption id="attachment_47547" align="aligncenter" width="1024"] Figure 4: New metadata filtering available in the UI and API[/caption]

Debugging Envoy configuration is essential when operating a mesh, so we’ve made it easy to see full XDS configuration for each data plane proxy in the UI, including a regex-enabled search capability to inspect config dump information without having to manually interact with the cluster.

[caption id="attachment_47548" align="aligncenter" width="1024"] Figure 5: Live search and debugging capabilities for Envoy data plane configuration[/caption]

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

[Get in touch with Kong](https://konghq.com/request-demo-kong-mesh)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](https://docs.konghq.com/mesh/2.1.x/install/)download Kong Mesh and get started for free.