このページは、まだ日本語ではご利用いただけません。翻訳中です。
Protocol support in Kong Mesh
At its core, Kong Mesh distinguishes between the following major categories of traffic: http
, grpc
, kafka
and opaque tcp
traffic.
For http
, grpc
and kafka
traffic Kong Mesh provides deep insights down to application-level transactions, in the latter tcp
case the observability is limited to connection-level statistics.
So, as a user of Kong Mesh, you’re highly encouraged to give it a hint whether your service supports http
, grpc
, kafka
or not.
By doing this,
- you will get richer metrics with
MeshMetric
policy - you will get richer logs with
MeshAccessLog
policy - you will be able to use
MeshTrace
policy
HTTP/2 support
Kong Mesh by default upgrades connection between Dataplanes to HTTP/2. If you want to enable HTTP/2 on connections between a dataplane and an application, use kuma.io/protocol: http2
tag.
TLS support
Whenever a service already initiates a TLS request to another service - and mutual TLS is enabled - Kong Mesh can enforce both TLS connections end-to-end as long as the service that is generating the TLS traffic is explicitly tagged with tcp
protocol (ie: kuma.io/protocol: tcp
).
Effectively
kuma-dp
will send the raw original TLS request as-is to the final destination, while in the meanwhile it will be enforcing its own TLS connection (if mutual TLS is enabled). Hence, the traffic must be marked as beingtcp
, sokuma-dp
won’t try to parse it.
Note that in this case no advanced HTTP or GRPC statistics or logging are available. As a best practice - since Kong Mesh will already secure the traffic across services via the mutual TLS policy - we suggest disabling TLS in the original services in order to get L7 metrics and capabilities.
Websocket support
Kong Mesh out of the box support’s Websocket
protocol. The service exposing Websocket
should be marked as tcp
.
As Websockets
use pure TCP
connections under the hood, your service have to be recognised by Kong Mesh as the TCP
one. It’s also the default behavior for Kong Mesh to assume the service’s inbound
interfaces are the TCP ones, so you don’t have to do anything, but if you want to be explicit, you can configure your services exposing Websocket
endpoints with appProtocol
property. I.e.: