Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 2.1.x (latest)
  • 2.0.x
  • 1.9.x
  • 1.8.x
  • 1.7.x
  • 1.6.x
  • 1.5.x
  • 1.4.x
  • 1.3.x
  • 1.2.x
  • 1.1.x
  • 1.0.x
    • Introduction to Kong Mesh
    • What is Service Mesh?
    • How Kong Mesh works
    • Deployments
    • Version support policy
    • Stability
    • Release notes
    • Installation Options
    • Kubernetes
    • Helm
    • OpenShift
    • Docker
    • Amazon ECS
    • Amazon Linux
    • Red Hat
    • CentOS
    • Debian
    • Ubuntu
    • macOS
    • Windows
    • Explore Kong Mesh with the Kubernetes demo app
    • Explore Kong Mesh with the Universal demo app
    • Standalone deployment
    • Multi-zone deployment
    • License
    • Overview
    • Data plane proxy
    • Data plane on Kubernetes
    • Data plane on Universal
    • Gateway
    • Zone Ingress
    • Zone Egress
    • CLI
    • GUI
    • Observability
    • Inspect API
    • Kubernetes Gateway API
    • Networking
    • Service Discovery
    • DNS
    • Kong Mesh CNI
    • Transparent Proxying
    • IPv6 support
    • Secure access across Kong Mesh components
    • Secrets
    • Kong Mesh API Access Control
    • API server authentication
    • Data plane proxy authentication
    • Zone proxy authentication
    • Data plane proxy membership
    • Dataplane Health
    • Fine-tuning
    • Control Plane Configuration
    • Upgrades
    • Requirements
    • Introduction
    • General notes about Kong Mesh policies
    • Applying Policies
    • How Kong Mesh chooses the right policy to apply
    • Understanding TargetRef policies
    • Protocol support in Kong Mesh
    • Mesh
    • Mutual TLS
    • Traffic Permissions
    • Traffic Route
    • Traffic Metrics
    • Traffic Trace
    • Traffic Log
    • Locality-aware Load Balancing
    • Fault Injection
    • Health Check
    • Circuit Breaker
    • Proxy Template
    • External Service
    • Retry
    • Timeout
    • Rate Limit
    • Virtual Outbound
    • MeshGateway
    • MeshGatewayRoute
    • Service Health Probes
    • MeshTrace (Beta)
    • MeshAccessLog (Beta)
    • MeshTrafficPermission (Beta)
    • Overview
    • HashiCorp Vault CA
    • Amazon ACM Private CA
    • cert-manager Private CA
    • OPA policy support
    • Multi-zone authentication
    • FIPS support
    • Certificate Authority rotation
    • Role-Based Access Control
    • UBI Images
    • Windows Support
    • Auditing
    • HTTP API
    • Annotations and labels in Kubernetes mode
    • Kong Mesh data collection
      • Mesh
      • CircuitBreaker
      • ExternalService
      • FaultInjection
      • HealthCheck
      • MeshGateway
      • MeshGatewayRoute
      • ProxyTemplate
      • RateLimit
      • Retry
      • Timeout
      • TrafficLog
      • TrafficPermission
      • TrafficRoute
      • TrafficTrace
      • VirtualOutbound
      • Dataplane
      • ZoneEgress
      • ZoneIngress
      • kuma-cp
      • kuma-dp
      • kumactl
    • Kuma-cp configuration reference

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this page
  • Components
  • Kubernetes mode
    • Services and Pods
  • Universal mode
Kong Mesh
2.0.x
  • Home
  • Kong Mesh
  • Explore
  • Overview
You are browsing documentation for an outdated version. See the latest documentation here.

Overview

This sections gives an overview of a Kong Mesh service mesh. It also covers how to start integrating your services into your mesh.

A Kong Mesh 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’s uses Envoy for its data plane proxy.
  • The control plane configures the data plane proxies for handling mesh traffic. However, the control plane runs independently of the data plane and does not 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.

Multi-mesh: one Kong Mesh control plane deployment can control multiple, isolated data planes using the Mesh resource. As compared to one control plane per data plane, this option lowers the complexity and operational cost of supporting multiple meshes.

This is a high level visualization of a Kong Mesh service mesh:

Communication happens between the control and data plane as well as between the services and their data plane proxies:

Kong Mesh implements the Envoy xDS APIs so that data plane proxies can retrieve their configuration from the control plane.

Components

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.

Users 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: users configure Kong Mesh via Kubernetes resources and Kong Mesh uses the Kubernetes API server as the data store.
  • universal: users 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 run a universal control plane on top of a Kubernetes cluster.

Kubernetes mode

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

The only step necessary to join your Kubernetes services to the mesh is enabling sidecar injection. For any Pods configured with sidecar injection, Kong Mesh adds the kuma-dp sidecar container. The following label on any Namespace or Pod controls this injection:

kuma.io/sidecar-injection: enabled

Injection: learn more about sidecar injection in the section on Dataplanes.

Annotations: see the complete list of the Kubernetes annotations.

Policies with Kubernetes: when using Kong Mesh in Kubernetes mode you create policies using kubectl and kuma.io CRDs.

Services and Pods

Pods with a Service

For all Pods associated with a Kubernetes Service resource, 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 a 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: example-client_kuma-example_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"]

Universal mode

When running in Universal mode, Kong Mesh requires a PostgreSQL database to store its state. This replaces the Kubernetes API. With Universal, you use kumactl to interact directly with the Kong Mesh API server to manage policies.

Read the docs about the PostgreSQL backend for more details.

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023