You are browsing documentation for a version of Kuma that is not the latest release.
Looking for even older versions? Learn more.
Protocol support in Kuma
At its core,
Kuma distinguishes between the following major categories of traffic:
kafka and opaque
kafka traffic Kuma 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 Kuma, you’re highly encouraged to give it a hint whether your service supports
kafka or not.
By doing this,
- you will get richer metrics with
- you will get richer logs with
- you will be able to use
Kubernetes, to give Kuma a hint that your service supports
HTTP protocol, you need to add a
<port>.service.kuma.io/protocol annotation to the
apiVersion: v1 kind: Service metadata: name: web namespace: kuma-example annotations: 8080.service.kuma.io/protocol: http # let Kuma know that your service supports HTTP protocol spec: selector: app: web ports: - port: 8080
Kuma 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.
Whenever a service already initiates a TLS request to another service - and mutual TLS is enabled - Kuma 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-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 being
kuma-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 Kuma 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.