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
Early Access
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 2.0.x (latest)
  • 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
    • Policy matching
    • 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
  • Usage
    • Creating resources in a Mesh
    • Controlling the passthrough mode
Kong Mesh
2.0.x (latest)
  • Home
  • Kong Mesh
  • Policies
  • Mesh

Mesh

This resource describes a very important concept in Kong Mesh, and that is the ability of creating multiple isolated service meshes within the same Kong Mesh cluster which in turn make Kong Mesh a very simple and easy project to operate in environments where more than one mesh is required based on security, segmentation or governance requirements.

Typically we would want to create a Mesh per line of business, per team, per application or per environment or for any other reason. Typically multiple meshes are being created so that a service mesh can be adopted by an organization with a gradual roll-out that doesn’t require all the teams and their applications to coordinate with each other, or as an extra layer of security and segmentation for our services so that - for example - policies applied to one Mesh do not affect another Mesh.

Mesh is the parent resource of every other resource in Kong Mesh, including:

  • Data plane proxies
  • Policies

In order to use Kong Mesh at least one Mesh must exist, and there is no limit to the number of Meshes that can be created. When a data plane proxy connects to the control plane (kuma-cp) it specifies to what Mesh resource it belongs: a data plane proxy can only belong to one Mesh at a time.

When starting a new Kong Mesh cluster from scratch a default Mesh is being created automatically.

Besides the ability of being able to create virtual service mesh, a Mesh resource will also be used for:

  • Mutual TLS, to secure and encrypt our service traffic and assign an identity to the data plane proxies within the Mesh.
  • Traffic Metrics, to setup metrics backend that will be used to collect and visualize metrics of our service mesh and service traffic within the Mesh.
  • Traffic Trace, to setup tracing backends that will be used to collect traces of our service traffic within the Mesh.
  • Zone Egress, to setup if ZoneEgress should be used for cross zone and external service communication.

When Mutual TLS is enabled in builtin mode, each Mesh will provision its own CA root certificate and key unless we explicitly decide to use the same CA by sharing the same certificate and key across multiple meshes. When the CAs of our Meshes are different, data plane proxies from one Mesh will not be able to consume data plane proxies belonging to another Mesh and an intermediate API Gateway must be used in order to enable cross-mesh communication. Kong Mesh supports a gateway mode to make this happen.

Usage

The easiest way to create a Mesh is to specify its name. The name of a Mesh must be unique.

Kubernetes
Universal
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default

We will apply the configuration with kubectl apply -f [..].

type: Mesh
name: default

We will apply the configuration with kumactl apply -f [..] or via the HTTP API.

Creating resources in a Mesh

It is possible to determine to what Mesh other resources belong to in the following ways.

Data plane proxies

Every time we start a data plane proxy, we need to specify to what Mesh it belongs, this can be done in the following way:

Kubernetes
Universal

By using the kuma.io/mesh annotation in a Deployment, like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
  namespace: kuma-example
spec:
  ...
  template:
    metadata:
      ...
      annotations:
        # indicate to Kong Mesh what is the Mesh that the data plane proxy belongs to
        kuma.io/mesh: default
    spec:
      containers:
        ...

A Mesh may span multiple Kubernetes namespaces. Any Kong Mesh resource in the cluster which specifies a particular Mesh will be part of that Mesh.

By using the -m or --mesh argument when running kuma-dp, for example:

kuma-dp run \
  --name=backend-1 \
  --mesh=default \
  --cp-address=https://127.0.0.1:5678 \
  --dataplane-token-file=/tmp/kuma-dp-backend-1-token

Policies

When creating new Policies we also must specify to what Mesh they belong. This can be done in the following way:

Kubernetes
Universal

By using the mesh property, like:

apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
mesh: default # indicate to Kong Mesh what is the Mesh that the resource belongs to
metadata:
  name: route-1
spec:
  ...

Kong Mesh consumes all Policies on the cluster and joins each to an individual Mesh, identified by this property.

By using the mesh property, like:

type: TrafficRoute
name: route-1
mesh: default # indicate to Kong Mesh what is the Mesh that the resource belongs to
...

Controlling the passthrough mode

In its default setup, Kong Mesh allows any non-mesh traffic to pass Envoy without applying any policy. For instance if a service needs to send a request to http://example.com, all requests won’t be logged even if a traffic logging is enabled in the mesh where the service is deployed. The passthrough mode is enabled by default on all the dataplane proxies in transparent mode in a Mesh. This behavior can be changed by setting the networking.outbound.passthrough in the Mesh resource. Example:

Kubernetes
Universal
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  networking:
    outbound:
      passthrough: false
type: Mesh
name: default
networking:
  outbound:
    passthrough: false

When networking.outbound.passthrough is false, no traffic to any non-mesh resource can leave the Mesh.

Before turning this feature on, double-check Envoy stats that no traffic is flowing through pass_through cluster. Otherwise, you will block the traffic which may cause the instability of the system.

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