Kmesh and the push to move service mesh traffic into the kernel

The data plane skips the proxy hop entirely

Kmesh is a high performance, low overhead service mesh data plane built on eBPF and a programmable kernel. The design decision that defines the project is stated plainly: Kmesh transparently intercepts and forwards traffic based on node local eBPF without introducing extra connection hops.

That is the whole argument against the sidecar model, and the project makes it with numbers attributed to the Istio documentation rather than to its own measurements. The extra latency of a proxy layer is given as 2 to 3 milliseconds, which the project documentation says cannot meet the SLA requirements of latency sensitive applications, and the resource cost as 0.5 vCPU and 50 MB of memory per 1000 requests per second going through the proxy, with a consequent drop in deployment density of the service container.

The claim underneath those figures is architectural. A sidecar proxy sits between two application pods and every request crosses it, so the cost is paid twice per call and scales with the number of pods rather than with the number of services. A node local eBPF data plane attaches to the network stack of the node itself, so the interception happens where traffic already flows.

What the project promises in its own feature list is a 60 percent reduction in forwarding delay, a 40 percent increase in workload startup performance, and a 70 percent reduction in service mesh data plane overhead. These are the project's published figures, and no test method is attached to them in the documentation. The performance section points at a Fortio based comparison of Kmesh and Envoy and at a Kmesh Performance Test document under test/performance, which is where a reader should look for the method behind the numbers.

Kmesh-daemon, eBPF orchestration and the waypoint split the work

Three components carry the design, and each has a clearly bounded job.

Kmesh-daemon is the per node management component. It handles bpf program management, subscribes to xDS configuration, and provides observability. This is the piece that reconciles the cluster's control plane with the kernel programs on each machine, and it is where the Istio shaped dependency list in the project's go.mod becomes visible, including istio.io/api and istio.io/istio itself.

The eBPF orchestration layer is the traffic orchestration implemented in eBPF. It supports L4 load balancing, traffic encryption, monitoring and simple L7 dynamic routing. Those four capabilities are the boundary of what runs in the kernel, and the word simple in that L7 line does a lot of work: what the kernel handles is HTTP level routing, not the full application protocol surface.

Waypoint is responsible for advanced L7 traffic governance, and it can be deployed separately per namespace or per service. This is the escape hatch for the cases the kernel path cannot cover, and it is deployed as its own workload rather than being bolted onto every pod, which preserves the sidecarless property for the workloads that do not need it.

The open ecology claim is supported by concrete dependencies: the project supports the XDS protocol standards and Gateway API, with sigs.k8s.io/gateway-api in the dependency list. That means the control plane side is familiar to anyone who has run a conventional mesh.

Dual-Engine Mode is the incremental path the project wants you to take

Kmesh names its kernel-first design Kernel-Native Mode, where Layer 4 and simple Layer 7 traffic governance sink into the kernel and the data path never passes through a proxy layer. On its own that is an all or nothing proposition: you either accept the limited L7 surface or you do not get a mesh.

Dual-Engine Mode is the answer to that. It uses eBPF and waypoint to process L4 and L7 traffic separately, so the two engines handle different traffic and you can adopt Kmesh incrementally. The documented path goes from no mesh, to a secure L4, to full L7 processing, and the point of staging it that way is that each stage is independently useful.

This is the design decision in the project worth arguing with, because it is where the marketing claim and the engineering reality meet. The 60 percent forwarding delay figure describes the kernel path, which is where eBPF does the work. Anything that needs waypoint involvement reintroduces a proxy hop, and no separate number is published for the dual-engine path.

For an operator, the practical reading is that Dual-Engine Mode makes Kmesh a migration tool rather than an all-or-nothing replacement. You can start with L4 where latency matters most, add waypoints for the services that need L7 policy, and stop there. A team that assumes the full L7 surface is available in kernel-native mode will find its first waypoint deployment is where the complexity reappears.

Getting it running: the quick start lives in the docs, not the repository

The repository does not carry a self contained install guide, and this is the first practical friction a new user hits. The documentation points to the quick start page on the project site and to a user guide document in the repository, and that is where the actual steps live.

There is also a guided path through a third party console. KubeStellar Console offers a guided installation mission for Kmesh with step by step instructions, pre-flight checks, validation, troubleshooting and rollback support. It works against a live cluster via kubeconfig, or as read only documentation without a cluster connection, which is a useful way to read through the procedure before you point it at anything.

The repository layout shows what a build produces. The `ctl/` directory is the command line tool, built on spf13/cobra, `daemon/` holds the Kmesh-daemon, `bpf/` holds the eBPF code including the licence files for the kernel module and data accelerate paths, `kernel/` and `cniplugin/` cover the kernel and CNI pieces, `deploy/` holds deployment manifests, and `samples/` contains the demo workloads used for trying the features, including circuit breaker, fortio, httpbin, sleep and tcp-echo samples.

The build itself is driven by a Makefile that compiles the Go user space with clang and clang++ for the BPF side, and it stitches the version, commit hash, tree state and build date into the binary through linker flags. The `mk/` directory holds the included bpf make fragments, and `build.sh` sits at the root next to the compile helper scripts for the kernel side.

The Go and Kubernetes versions the dependency list commits you to

The go.mod file is the clearest statement of what a consumer inherits. The module declaration and the language version look like this:

module kmesh.net/kmesh
go 1.24.2

So the toolchain floor is recent.

The Kubernetes side is pinned to 0.32.2 across the whole client set, with k8s.io/api, apimachinery, cli-runtime, client-go, kubectl and utils all at that version. The Istio shaped dependencies are istio.io/api at v1.24.3 plus istio.io/istio and istio.io/pkg, and control plane communication goes through cncf/xds/go and envoyproxy/go-control-plane. Gateway API support is sigs.k8s.io/gateway-api v1.2.1.

Two entries stand out for operational planning. containernetworking/cni at v1.3.0 and containernetworking/plugins at v1.9.0 mean the CNI plugin is part of the deployment, so installing Kmesh means changing how pods get their network setup on the node. safchain/ethtool is in the list, which is what a data plane uses to read link settings.

Observability runs through prometheus/client_golang v1.21.0 and prometheus/common v0.62.0, so metrics come from the standard Prometheus client rather than a bespoke exporter. The eBPF programs are loaded with github.com/cilium/ebpf v0.17.3, and the build requires both a Go toolchain and clang, which is a heavier build environment than a pure Go project.

One replace directive is worth noting because it is the kind of thing that breaks a build for a newcomer. The module replaces github.com/imdario/mergo with version v0.3.5, with a comment explaining that client-go does not handle different versions of mergo because of breaking changes. A dependency upgrade that ignores this pin will fail in a way that does not point at the cause.

Licence split: Apache-2.0 in user space, a choice for the BPF side

Kmesh does not use a single licence, and the split follows the code boundary.

The user space components are licensed under the Apache License, Version 2.0. That covers the daemon, the CLI and the rest of the Go side.

The BPF code templates, the ko kernel module and the mesh data accelerate are a different case. They are dual licensed under the General Public License, Version 2.0 (only) and the 2-Clause BSD License, and the documentation states that you can use the terms of either licence at your option.

That option matters more than a typical dual licence note, because GPL-2.0-only on a kernel module or on code that links into the kernel is not the same obligation as GPL-2.0-or-later. For a team that wants to avoid GPL obligations on distributed kernel facing artifacts, the BSD option is the path, and it is available without asking anyone. This is a licensing fact, not advice about what your situation is.

The project also carries the usual governance files. LICENSE, NOTICE, SECURITY.md, MAINTAINERS.md, OWNERS, CODE_OF_CONDUCT.md and CONTRIBUTING.md sit at the root, and a kmesh.spec file is present, which is the packaging recipe for RPM based distributions, consistent with a project that was incubated in the openEuler community.

Where the kernel path ends and the waypoint picks up

The honest limitations are visible in the component list, and they are structural rather than incidental.

First, the L7 surface in the kernel is the simple one. The eBPF orchestration supports simple L7 dynamic routing, while advanced L7 traffic governance belongs to the waypoint. A service that needs per-request policy that the kernel path cannot express will need a waypoint, and once a waypoint is in the request path the latency advantage of the kernel path no longer applies to that traffic.

Second, the comparison numbers in the feature list describe the kernel path, and no separate figure is published for dual-engine traffic. Anyone with an SLA that depends on where the proxy hop sits should treat the waypoint path as a separate case to measure rather than assume the same numbers apply.

Third, the deployment surface is larger than a single binary. eBPF programs must load onto the kernel, a CNI plugin is part of the install, and the daemon runs per node. That means the operating requirements move from a Kubernetes namespace to the node itself, and kernel version and eBPF feature availability become part of your compatibility matrix. No minimum kernel version is documented, which is the first number a platform team will ask for.

The release cadence is worth tracking too. The most recent release is v1.2.0 on 2025-12-09, preceded by v1.2.0-rc.0 on 2025-12-02 and v1.1.0 on 2025-05-15, while the last push to the main branch was on 2026-10-15. The branch is moving faster than the release tags, so the tags lag the code you would actually deploy from main.

Against a conventional sidecar mesh, the difference is where the proxy lives

The alternative worth naming is the sidecar mesh the project itself uses as its baseline, Istio, and the difference in approach is specific rather than a matter of degree.

A sidecar mesh places a proxy process next to every application container. Every connection between two services crosses two proxies, one on each side, and the cost of that arrangement scales with pod count. Kmesh keeps the interception in node local eBPF and routes it through the kernel, so the per-pod resource line item and the extra hop both go away for L4 and simple HTTP traffic.

The cost moves rather than disappears. A conventional mesh gives you a mature L7 story at every hop, with policy enforcement, telemetry and protocol handling handled by a component that is easy to reason about and easy to debug. Kmesh splits that story: the kernel handles what it can handle, and everything else moves to a waypoint that is deployed per namespace or per service. The Dual-Engine Mode exists to make that split tolerable, and it does, but it is a different operating model from a uniform sidecar.

The same difference shows up in what the two approaches require from the platform. The sidecar model needs a proxy image and a sidecar injection step, and it stays inside the container boundary. Kmesh needs eBPF support in the kernel, a CNI plugin, a per node daemon and permission to load BPF programs, which is a different set of conversations with a platform team, and a set of conversations that a group already running eBPF based networking may have had before.

For an operator whose pain is per-pod resource cost or per-hop latency, that difference is the reason to look at Kmesh. For one whose pain is missing L7 features, the sidecar path remains the more direct answer.

Editorial conclusion

Kmesh fits operators who have already decided they want a mesh, run a kernel they can load eBPF programs onto, and cannot absorb the per-pod cost of a sidecar proxy, particularly for latency sensitive or high density services. It is the wrong choice for a team whose first requirement is full L7 governance everywhere, because the L7 work has to be moved to waypoint components and the Dual-Engine Mode exists precisely because Kernel-Native mode does not cover it. Before adopting, verify two things: that the kernel on every node meets the eBPF requirements the project documents, and whether the licence split suits you, since the user space is Apache-2.0 while the BPF templates, ko kernel module and mesh data accelerate are offered under GPL-2.0-only or 2-Clause BSD at your option. The last push was on 2026-10-15 and the most recent release was v1.2.0 on 2025-12-09, so treat the release tags as older than the branch.

Frequently asked questions

Official sources

1. kmesh-net/kmesh on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases