Dataplane Specification

The Dataplane entity includes the networking and naming configuration that a data-plane proxy (kuma-dp) must have attempting to connect to the control-plane (kuma-cp).

In Universal mode we must manually create the Dataplane entity before running kuma-dp. A Dataplane entity can be created with kumactl or by using the HTTP API. When using kumactl, the entity definition will look like:

type: Dataplane
mesh: default
name: web-01
networking:
  inbound:
  - interface: 127.0.0.1:11011:11012
    tags:
      service: backend
  outbound:
  - interface: :33033
    service: redis

The Dataplane entity includes a few sections:

• type: must be Dataplane.
• mesh: the Mesh name we want to associate the data-plane with.
• name: this is the name of the data-plane instance, and it must be unique for any given Mesh. We might have multiple instances of a Service, and therefore multiple instances of the sidecar data-plane proxy. Each one of those sidecar proxy instances must have a unique name.
• networking: this is the meaty part of the configuration. It determines the behavior of the data-plane on incoming (inbound) and outgoing (outbound) requests.
  • inbound: an array of interface objects that determines what services are being exposed via the data-plane. Each interface object only supports one port at a time, and you can specify more than one interface in case the service opens up more than one port.
    • interface: determines the routing logic for incoming requests in the format of {address}:{dataplane-port}:{service-port}.
    • tags: each data-plane can include any arbitrary number of tags, with the only requirement that service is mandatory and it identifies the name of service. You can include tags like version, cloud, region, and so on to give more attributes to the Dataplane (attributes that can later on be used to apply policies).
  • outbound: every outgoing request made by the service must also go thorugh the DP. This object specifies ports that the DP will have to listen to when accepting outgoing requests by the service:
    • interface: the address inclusive of the port that the service needs to consume locally to make a request to the external service
    • service: the name of the service associated with the interface.

On Kubernetes this whole process is automated via transparent proxying and without changing your application's code. On Universal Kuma doesn't support transparent proxying yet, and the outbound service dependencies have to be manually specified in the Dataplane entity. This also means that in Universal you must update your codebases to consume those external services on 127.0.0.1 on the port specified in the outbound section.