Revolutionizing Service Mesh: The Shift to eBPF Technology
Written on
Understanding Service Mesh
If you're in software development, you might already be aware of the rising trend of Service Mesh technology. For the past two to three years, it has gained traction in mainstream development practices. According to InfoQ's Software Architecture Trends report in 2021, Service Mesh has transitioned into the Early Majority phase.
Source — InfoQ Service Mesh Overview
In an article I wrote back in October 2020 titled "The Roles of Service Mesh and API Gateways in Microservice Architecture," I delved into the intricacies of Service Mesh technology. For a brief refresher, a service mesh manages the communication between different services within a distributed software ecosystem. Specifically, it oversees east-west network traffic, which refers to the data flow within a data center, Kubernetes cluster, or distributed environment.
Exploring Service Mesh Models
Currently, there are two prominent models of Service Mesh:
- Shared Library Model
- Sidecar Proxy Model
In the Shared Library Model, applications utilize language-specific libraries to implement Service Mesh features. While there isn't a single library that encompasses all functionalities, developers often employ a combination of libraries.
Image by Author
The Sidecar Proxy Model, however, has emerged as the more prevalent approach today. In this model, functionalities related to the service mesh are executed by running a sidecar proxy alongside the application. Sidecar Proxies are critical components of service meshes, providing essential features such as Networking, Security, and Observability.
Challenges of Sidecar Proxy Models
Practitioners have identified several challenges with the Sidecar Proxy Service Mesh Model over time. Each application service requires an additional sidecar, leading to increased costs and resource consumption. For instance, an article by Pranay Singhal highlights the issue of Envoy Proxies consuming excessive memory in large deployments. Additionally, there may be performance impacts associated with implementing service meshes, which have been discussed in other articles. Monitoring both application services and their corresponding sidecars also adds complexity, along with the overhead of deploying and maintaining these sidecars.
Given recent advancements in eBPF technology, solutions to these challenges are emerging.
Introducing eBPF-Based Service Mesh
Cilium has recently introduced an eBPF-based Service Mesh concept, which utilizes an eBPF plugin running in the kernel to enhance network, security, and observability capabilities. If you're unfamiliar with eBPF, I recommend checking out my article on the subject.
In this video, industry experts discuss the future of Service Mesh technologies, weighing the benefits of sidecar versus sidecarless implementations.
The diagram below illustrates how an eBPF-based Service Mesh Model operates.
Image by Author
Cilium already extends several service mesh capabilities with eBPF, including:
- Identity-based security
- L3-L7 observability and authorization
- Encryption
- Load balancing
Additionally, features currently being beta-tested include:
- L7 Traffic Management & Load Balancing (HTTP, gRPC, etc.)
- Topology-aware routing across clusters, clouds, and on-premises
- TLS termination
- Canary rollouts, retries, rate limiting, circuit breaking, and more, all managed through Envoy
- Tracing integration with OpenTelemetry and Jaeger
- Built-in Kubernetes Ingress Support
The Evolution of Service Mesh Models
There are numerous advantages to adopting eBPF-based services:
- Initial tests indicate significant improvements in HTTP latency visibility compared to sidecar proxy visibility.
Unlike the sidecar model, the eBPF-based approach can minimize the number of proxies needed. For example, if you run 30 services on a node, the sidecar model would necessitate 30 sidecars, whereas the eBPF model requires only one proxy per node. This reduction in proxies leads to decreased deployment complexity, memory usage, and resource overhead.
Conclusion
eBPF has the potential to transform service mesh implementations into a native and highly efficient process. This transition could liberate us from reliance on the sidecar model, allowing for the integration of existing proxy technologies into kernel namespace concepts, thus enhancing the container abstraction we utilize daily. Furthermore, eBPF can shift more functions currently managed by proxies, thereby reducing both overhead and complexity.
In this second video, experts compare sidecar-less service meshes from Cilium and Istio, discussing their respective advantages and use cases.
References
If you found this article insightful, consider joining Medium Membership for just $5/month. Your support helps me and other writers, and you’ll gain access to all stories on Medium.