You are browsing documentation for the next version of Kuma. Use this version at your own risk.
Data plane proxy
A data plane proxy (DPP) is the part of Kuma that runs next to each workload that is a member of the mesh. A DPP is composed of the following components:
Dataplaneentity defines the configuration of the DPP
kuma-dpbinary runs on each instance that is part of the mesh. This binary spawns the following subprocesses:
Envoyreceives configuration from the control-plane to manage traffic correctly
core-dnsresolves Kuma specific DNS entries
Data plane proxies are also called sidecars.
We have one instance of
kuma-dp for every instance of every service.
An inbound consists of:
- a set of tags
- the port the workload listens on
Most of the time a DPP exposes a single inbound. When a workload exposes multiple ports, multiple inbounds can be defined.
Tags are a set of key-value pairs (.e.g
version=v2) that are defined for each DPP inbound. These tags serve the following purposes:
- specifying the service this DPP inbound is part of
- adding metadata about the exposed service
- allowing subsets of DPPs to be selected by these tags
Tags prefixed with
kuma.io are reserved:
kuma.io/serviceidentifies the service name. On Kubernetes this tag is automatically created, while on Universal it must be specified manually. This tag must always be present.
kuma.io/zoneidentifies the zone name in a multi-zone deployment . This tag is automatically created and cannot be overwritten.
kuma.io/protocolidentifies the protocol of the service exposed by this inbound. Accepted values are
A service is a group of all DPP inbounds that have the same
An outbound allows the workload to consume a service in the mesh using a local port. This is only useful when not using (/docs/dev/production/dp-config/transparent-proxying/) .
Dataplane entity consists of:
- the IP address used by other DPPs to connect to this DPP
Dataplane entity must be present for each DPP.
Dataplane entities are managed differently depending on the environment:
- Kubernetes: The control plane
- Universal: The
For more details check the dataplane specification:
Dynamic configuration of the data plane proxy
When the DPP runs:
kuma-dpretrieves Envoy startup configuration from the control plane.
kuma-dpprocess starts Envoy with this configuration.
- Envoy connects to the control plane using XDS and receives configuration updates when the state of the mesh changes.
The control plane uses policies and
Dataplane entities to generate the DPP configuration.
Data plane proxy ports
When we start a data-plane via
kuma-dp we expect all the inbound and outbound service traffic to go through it. The inbound and outbound ports are defined in the dataplane specification when running in universal mode, while on Kubernetes the service-to-service traffic always runs on port
In addition to the service traffic ports, the data-plane automatically also opens the
envoy administration interface listener on the