Stable, simple and high performance sidecarless service mesh
At the beginning of the new year 2025, we are thrilled to announce the official release of Kmesh v1.0.0. We extend our heartfelt gratitude to all Kmesh community contributors for their relentless efforts and hard work over the past three months. Without everyone’s collective effort, we can not achieve this successful release.
In this v1.0 release, Kmesh has made substantial improvements to its east-west traffic management functionality, enhancing overall network traffic management efficiency and security. These enhancements not only optimize data transmission stability but also provide users with more robust traffic governance capabilities. Additionally, we have continually refined the usability of Kmesh, making it more user-friendly and intuitive, allowing users to get started quickly and easily.
Main features of Kmesh release v1.0:
Encrypted communication
To ensure the security of communication, Kmesh has introduced IPsec in v1.0 release to encrypt traffic between nodes, converting plaintext to ciphertext during transmission and ensuring data security. The overall architecture is illustrated in the diagram below:
IPsec, as a mature, stable, and highly secure encryption protocol, is widely used in various network environments. It not only provides encryption for inter-node communication but also supports the encryption of data across different protocols. Kmesh utilizes only the encryption functionality of IPsec. As shown in the diagram, after users set up the IPsec pre-shared key in Kubernetes, Kmesh manages this key to ensure the proper functioning of IPsec communication.
Additionally, to finely control the encryption behavior of IPsec, Kmesh stores node information through the “KmeshNodeInfo” CRD (Custom Resource Definition), leveraging the Kubernetes API server for inter-node information synchronization. This ensures the security of communication between cluster nodes.
With IPsec, Kmesh not only achieves encrypted inter-node communication but also ensures the confidentiality and integrity of data during transmission, effectively preventing data from being eavesdropped, tampered with, or forged. By combining the flexibility of Kubernetes and the extensibility of CRD (Custom Resource Definition), Kmesh can efficiently manage encryption keys and dynamically synchronize node information in complex cluster environments, further enhancing the overall system’s security and reliability.
Offload authorization execution into XDP prog
In Kmesh v0.5.0, some authorization functionalities were offloaded to XDP programs. In the v1.0 release, we have further extended these capabilities, now supporting IP-based authorization handling. The overall processing flow is depicted in the diagram below:
Kmesh divides the authorization processing into four steps: policy, rule, clause, and match, linking them together using the tail-call mechanism. The entire authorization process occurs during the TCP connection establishment. If the authorization is successful, traffic is sent to the corresponding IP address via the protocol stack. If authorization fails, the SYN packet is discarded, preventing the TCP connection from being established.
By offloading authorization to XDP programs, Kmesh can perform authorization at the earliest stage when network packets enter the kernel protocol stack. This approach significantly reduces the overhead of context switching between user space and kernel space, greatly enhancing packet processing efficiency, and achieving high-speed, low-latency authorization. This design ensures that unauthorized packets are discarded directly within the protocol stack, effectively reducing system resource consumption and enhancing overall security and performance.
In future releases, Kmesh plans to offload more authorization functionalities to XDP programs. We welcome the community to provide their authorization requirements to help shape our iteration plans.
Locality load balance
Kmesh v1.0 introduces Locality load balancing capability. Locality load balancing is a crucial optimization for performance and reliability in distributed systems. By directing traffic to the nearest service instance, it reduces latency and increases availability.
In the example shown in the diagram, priorities 1, 2, 3, and 4 indicate the order in which a client accesses a service. When accessing a service, the priority is calculated based on the match levels of sub-zone, zone, and region, determining which service to access first. The locality priority information stored in user space updates the service map. The BPF program uses the priority information in the service map to select the corresponding endpoint for connection.
Additionally, during load balancing policy updates, Kmesh updates each “endpoint_key” in the endpoint map to ensure service continuity. Kmesh now supports five levels of locality load balancing: region, zone, subZone, nodeName, and clusterID, allowing users to flexibly configure their load balancing strategies.
With locality load balancing, Kmesh can intelligently route traffic to the optimal node, reducing latency and improving service performance. This ensures faster responses to user requests, significantly enhancing the overall user experience and network performance, especially for large-scale distributed applications spanning multiple regions.
Observability enhancement
To enhance the usability of Kmesh, the Kmesh v1.0 includes optimizations tailored to user needs in observability.
For Metrics, Kmesh has improved the metrics labels by replacing the “destination_service” from the original destination service to the real destination of the request. Previously, a request from the source to the destination through a waypoint would be split into two metrics: “source->waypoint” and “waypoint->destination”. Now, the destination information is consistently presented as the final destination, providing clearer and more accurate metrics.
# before release v1.0
# destination_service_name is `reviews` instead of `reviews-svc-waypoint
kmesh_tcp_connections_closed_total{destination_app=”reviews-svc-waypoint”,destination_service=”reviews-svc-waypoint”…} 14
When multiple services share a waypoint, the metrics can be confusing for users. However, in the v1.0 release, Kmesh metrics ensure that the “”destination_service“” always records the final destination information. This change means that a single metric will now include both the waypoint and the final destination information, making the metrics more understandable and logical.
# release v1.0
# destination_service_name is `reviews` instead of `reviews-svc-waypoint`
kmesh_tcp_connections_closed_total{destination_app=”reviews-svc-waypoint”,destination_service_name=”reviews”…} 14
This enhancement improves the overall clarity and usability of Kmesh’s observability data.
Additionally, Kmesh integrates with Kiali to provide users with a clear and intuitive service topology graph.
With the service topology graph, users can comprehensively understand the dependencies and communication status between services in the cluster. This makes it easier to monitor and diagnose network conditions. Users can also identify potential performance bottlenecks and failure points, enabling optimization and troubleshooting to improve the overall system reliability and performance.
All mode now support zero-downtime restart
In the v1.0 release, Kmesh’s Kernel-Native mode also supports sustainable traffic management without breaking inflight connections during restart. It gracefully loads eBPF maps and programs after a restart without needing to re-register services, achieving the goal of uninterrupted traffic across all Kmesh modes.
Similar to the Dual-Engine mode, eBPF programs and maps are pinned to the kernel directory, decoupling them from the kmesh-daemon. This ensures that eBPF maps and programs continue to manage traffic even when Kmesh is down, maintaining service continuity during Kmesh restarts.
If there are configuration updates during a Kmesh restart, Kmesh will fetch the latest configurations from istiod upon restart, ensuring immediate synchronization.
Unlike traditional Service Meshes that interrupt traffic during restarts, Kmesh’s design ensures uninterrupted service, enhancing system reliability and availability, reducing service disruption risks, and improving user experience. Additionally, Kmesh plans to support seamless upgrades in the future, allowing users to adopt new features without impacting business traffic.
Support rate limit and circuit breaker
Note: This feature is currently available in [Kernel-Native Mode].
Kmesh v1.0 introduces circuit breaking and rate limiting in Kernel-Native Mode. This ensures system stability and reliability while maintaining low latency, high concurrency, and high load performance. Although Kernel-Native Mode aims for optimal performance, it previously had fewer features. We will continue to add more functionalities while ensuring performance remains exceptional.
Support Headless Service, ServiceEntry and Adapt Istio 1.24
In Kmesh v1.0, compatibility with Istio 1.24 has been achieved, and end-to-end (e2e) tests have ensured Kmesh’s stability on Istio 1.24. The Kmesh community has also verified stability through e2e tests on Istio versions 1.22, 1.23, and 1.24. Compared with Ambient Mesh, Kmesh has superior latency and throughput.
Besides supporting the latest Istio version, Kmesh now also supports some capabilities of Headless Service and ServiceEntry. With this, Kmesh can manage traffic to stateful applications and external services.
Acknowledgment
We extend our heartfelt gratitude to all contributors of the Kmesh community. The successful release of Kmesh v1.0.0 is a testament to the collective efforts of the entire team. This includes not only students who participated through OSPP but also enthusiastic open-source developers from companies like Huawei,Alibaba, and Tetrate. It is everyone’s combined effort that has led to the thriving growth of the Kmesh community.
We warmly welcome new developers and users to join the Kmesh community. Continuous participation and support are essential for ongoing innovation and progress. Together, we can drive Kmesh towards a brighter future. Through collaboration and sharing, we look forward to achieving more technical breakthroughs and applications, providing an excellent Sidecarless service mesh solution for all.
References
[1]Kmesh v1.0.0: https://github.com/kmesh-net/kmesh/releases/tag/v1.0.0
[2]Kmesh GitHub: https://github.com/kmesh-net/kmesh
[3]Kmesh Website: https://kmesh.net/en/
[4]Traffic Management Architecture Comparison: When Kmesh Meets Ambient Mesh：https://bbs.huaweicloud.com/blogs/442565
[5]Kmesh v0.5.0:https://github.com/kmesh-net/kmesh/releases/tag/v0.5.0