Dataplane Entity

A Dataplane entity must be created on the CP kuma-cp before a kuma-dp instance attempts to connect to the control-plane. On Kubernetes, this operation is fully automated. On Universal, it must be executed manually.

To understand why the Dataplane entity is required, we must take a step back. As we have explained already, Kuma follow a sidecar proxy model for the data-planes, where we have an instance of a data-plane for every instance of our services. Each Service and DP will communicate with each other on the same machine, therefore on 127.0.0.1.

For example, if we have 6 replicas of a "Redis" service, then we must have one instances of kuma-dp running alongside each replica of the service, therefore 6 replicas of kuma-dp as well.

Dataplane Entity - 图1

Many DPs! The number of data-planes that we have running can quickly add up, since we have one replica of kuma-dp for every replica of every service. That's why it's important for the DP process to be lightweight and consume a few resources, otherwise we would quickly run out of memory, especially on platforms like Kubernetes where multiple services are running on the same underlying host machine. And that's one of the reasons why Kuma leverages Envoy for this task.

When we start a new data-plane in Kuma, two things have to happen:

  • The data-plane needs to advertise what service it is responsible for. This is what the Dataplane entity does.

  • The data-plane process needs to start accepting incoming and outgoing requests. These steps are being executed in two separate commands:

  • We register the Dataplane object via the kumactl or HTTP API.

  • Once we have registered the DP, we can start it by running kuma-dp run.

Remember: this is all automated if you are running Kuma on Kubernetes!

The registration of the Dataplane includes two main sections that are described below in the Dataplane Specification:

  • inbound networking configuration, to configure on what port the DP will listen to accept external requests, specify on what port the service is listening on the same machine (for internal DP <> Service communication), and the Tags that belong to the service.
  • outbound networking configuration, to enable the local service to consume other services. For example, this is how we register a Dataplane for an hypotetical Redis service and then start the kuma-dp process:
  1. echo "type: Dataplane
  2. mesh: default
  3. name: redis-1
  4. networking:
  5.   inbound:
  6.   - interface: 127.0.0.1:9000:6379
  7.     tags:
  8.       service: redis" | kumactl apply -f -
  10. KUMA_CONTROL_PLANE_BOOTSTRAP_SERVER_URL=http://control-plane:5682 \
  11. KUMA_DATAPLANE_MESH=default \
  12. KUMA_DATAPLANE_NAME=redis-1 \
  13. kuma-dp run

12345678910111213

In the example above, any external client who wants to consume Redis will have to make a request to the DP on port 9000, which internally will be redirected to the Redis service listening on port 6379.

Now let's assume that we have another service called "Backend" that internally listens on port 80, and that makes outgoing requests to the redis service:

  1. echo "type: Dataplane
  2. mesh: default
  3. name: backend-1
  4. networking:
  5.   inbound:
  6.   - interface: 127.0.0.1:8000:80
  7.     tags:
  8.       service: backend
  9.   outbound:
  10.   - interface: :10000
  11.     service: redis" | kumactl apply -f -
  13. KUMA_CONTROL_PLANE_BOOTSTRAP_SERVER_URL=http://control-plane:5682 \
  14. KUMA_DATAPLANE_MESH=default \
  15. KUMA_DATAPLANE_NAME=redis-1 \
  16. kuma-dp run

In order for the backend service to successfully consume redis, we specify an outbound networking section in the Dataplane configuration instructing the DP to listen on a new port 10000 and to proxy any outgoing request on port 10000 to the redis service. For this to work, we must update our application to consume redis on 127.0.0.1:10000.

As mentioned before, this is only required in Universal. In Kubernetes no change to our applications are required thanks to automated transparent proxying.