Kong Mesh architecture

A Kong Mesh service mesh consists of two main components:

• The data plane consists of the proxies that run alongside your services. All of your mesh traffic flows through these proxies on its way to its destination. Kong Mesh uses Envoy for its data plane proxy.
• The control plane configures the data plane proxies for handling mesh traffic. The control plane runs independently of the data plane and doesn’t interact with mesh traffic directly. Kong Mesh users create policies that the Kong Mesh control plane processes to generate configuration for the data plane proxies.

One Kong Mesh control plane deployment can control multiple isolated data planes using the Mesh resource. Compared to using one control plane per data plane, this option lowers the complexity and operational cost of supporting multiple meshes.

Here’s a diagram that shows the Kong Mesh architecture :

 
flowchart TB
    CP[Control plane]
      subgraph M[Mesh]
        direction LR
        subgraph S1[Service]
            subgraph DP1[Data plane]
                DPP1[Data plane proxy]
            end
        end
        subgraph S2[Service]
            subgraph DP2[Data plane]
                DPP2[Data plane proxy]
            end
        end
        DPP1 <--> DPP2
    end

    CP <----> DPP1 & DPP2
  

Data plane proxies handle two types of communication:

• Configuration retrieval from the control plane using the Envoy xDS APIs.
• Request proxying for all traffic to and from the service.

A minimal Kong Mesh deployment involves one or more instances of the control plane executable kuma-cp. For each service in your mesh, you’ll have one or more instances of the data plane proxy executable kuma-dp.

You can interact with the control plane via the command-line tool kumactl.

There are two modes that the Kong Mesh control plane can run in:

• kubernetes: Configure Kong Mesh via Kubernetes resources and Kong Mesh uses the Kubernetes API Server as the data store.
• universal: Configure Kong Mesh via the Kong Mesh API server and Kong Mesh resources. PostgreSQL serves as the data store. This mode works for any infrastructure other than Kubernetes, though you can also run a universal control plane on top of a Kubernetes cluster.

When running in Kubernetes mode, Kong Mesh stores all of its state and configuration on the underlying Kubernetes API Server.

Enable sidecar injection to add Pods to the mesh. Kong Mesh injects the kuma-dp sidecar container into any Pod configured for injection. The following label on a Namespace or Pod controls this behavior:

kuma.io/sidecar-injection: enabled

For more information, see:

• Kong Mesh on Kubernetes
• Kubernetes annotations
• Policies

Services and Pods

Pods with Service

For all Pods associated with a Kubernetes Service resource, the Kong Mesh control plane automatically generates an annotation kuma.io/service: <name>_<namespace>_svc_<port> where <name>, <namespace> and <port> come from the Service.

For example, the following resources generates kuma.io/service: echo-server_kuma-test_svc_80:

apiVersion: v1
kind: Service
metadata:
  name: echo-server
  namespace: kuma-test
  annotations:
    80.service.kuma.io/protocol: http
spec:
  ports:
    - port: 80
      name: http
  selector:
    app: echo-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-server
  namespace: kuma-test
  labels:
    app: echo-server
spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: echo-server
  template:
    metadata:
      labels:
        app: echo-server
    spec:
      containers:
        - name: echo-server
          image: nginx
          ports:
            - containerPort: 80

Pods without Service

In some cases Pods don’t belong to a corresponding Service. This is typically because they don’t expose any consumable services. Kubernetes Jobs are a good example of this.

In this case, the Kong Mesh control plane generates a kuma.io/service tag with the format <name>_<namespace>_svc, where <name> and<namespace> come from the Pod resource itself.

The Pods created by the following example Deployment have the tag kuma.io/service: echo-client_default_svc:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-client
  labels:
    app: echo-client
spec:
  selector:
    matchLabels:
      app: echo-client
  template:
    metadata:
      labels:
        app: echo-client
    spec:
      containers:
        - name: alpine
          image: "alpine"
          imagePullPolicy: IfNotPresent
          command: ["sh", "-c", "tail -f /dev/null"]

When running in Universal mode, Kong Mesh requires a PostgreSQL database to store its state. You can use kumactl to interact with the Kong Mesh API server to manage policies. For more information, see the PostgreSQL section in the control plane configuration docs.