What Is Sidecarless?
What Is a Sidecarless Service Mesh?
A sidecarless service mesh is an approach to service mesh design that eliminates the use of sidecar proxies for managing network traffic between microservices. Traditionally, service meshes like Istio or Linkerd use a sidecar proxy (e.g., Envoy) that is deployed alongside each service instance, handling tasks like traffic routing, security, and observability.
In a sidecarless model, these functions are typically moved out of individual service pods and are instead handled in a centralized manner or through other architectures. This could involve:
- Node-level proxies: Instead of deploying a proxy alongside each service, a single proxy is deployed at the node level (hosted on each VM or Kubernetes node) to manage traffic for all services on that node.
- eBPF-based service mesh: Some service meshes, like Cilium, leverage eBPF (Extended Berkeley Packet Filter) in the Linux kernel to manage network traffic, security, and observability directly, without the need for sidecars.
- Distributed networking infrastructure: In some architectures, traffic management and security may be pushed further down into the networking layer or infrastructure, using routers, gateways, or cloud-native networking capabilities to handle traffic between services.
Benefits of Sidecarless Service Mesh
- Reduced resource overhead: Removing sidecars reduces CPU and memory consumption because fewer proxy containers are deployed and maintained.
- Improved simplicity: It simplifies the deployment model, reducing operational complexity since there are fewer moving parts (i.e., no need to manage individual sidecar containers).
- Potential performance gains: Reduced latency can result from eliminating the sidecar, which typically adds overhead by processing each service request.
Challenges
- Centralization risks: Moving traffic management to centralized points could create bottlenecks or single points of failure.
- Limited flexibility: Sidecar proxies provide per-service configuration and isolation, which can be harder to achieve with centralized or node-level proxies.
This emerging approach is still evolving, and it’s gaining traction as a way to streamline service mesh deployment while maintaining many of the traffic management and security benefits.
What Is Istio sidecarless?
Istio Sidecarless is a new approach being developed within the Istio ecosystem that moves away from the traditional sidecar proxy architecture, while still retaining the core benefits of a service mesh, like traffic management, security, and observability.
What Is Istio Sidecarless?
In the initial Istio architecture, each service has an Envoy proxy deployed as a sidecar container within the same pod, intercepting and managing all inbound and outbound traffic. Istio sidecarless eliminates this per-service sidecar deployment by instead using a different method for traffic management.
The idea behind Istio Sidecarless is to:
- Remove the need for sidecar proxies for each service instance.
- Instead, leverage node-level proxies or other traffic handling mechanisms like eBPF (Extended Berkeley Packet Filter), where traffic management is done at the node level, bypassing the need for sidecar containers at each service pod.
This can involve:
- Node-wide Envoy proxies: Instead of deploying one Envoy per pod, a single Envoy proxy is deployed per node, managing traffic for all services running on that node.
- eBPF integration: Some emerging models leverage eBPF in the Linux kernel, allowing traffic redirection and security enforcement to happen at the kernel level rather than in user-space sidecars.
How is Istio Sidecarless Different from Other Sidecarless Service Meshes?
While Istio is embracing the sidecarless model, other service meshes have already implemented similar architectures but with different focuses and underlying technologies.
Here’s how Istio Sidecarless compares to some other sidecarless service meshes:
1. Cilium with eBPF:
- eBPF-based service mesh: Cilium primarily relies on eBPF in the Linux kernel to manage networking, security, and observability without using sidecar proxies.
- Direct kernel-level control: Instead of node-level or sidecar proxies, Cilium programs network behavior directly into the Linux kernel, resulting in lower latency and overhead.
Difference from Istio: Istio, in its sidecarless form, may still rely on Envoy proxies (at the node level), whereas Cilium eliminates proxies entirely by using eBPF.
2. Linkerd:
- No heavy proxy overhead: While Linkerd still uses sidecars in most cases, it focuses on using a lighter proxy (Linkerd’s own proxy) instead of heavier alternatives like Envoy.
- No sidecar model (future developments): Linkerd is exploring models similar to Istio’s sidecarless approach but focuses on simplicity, reducing resource overhead while retaining the core benefits of service mesh.
Difference from Istio: Linkerd prioritizes simplicity and lightweight proxies, whereas Istio’s sidecarless approach still involves Envoy (though potentially at the node level).
3. Kuma (Kong Mesh):
- Mesh Gateway-centric: Kuma (from Kong) offers a service mesh that uses mesh gateways to centralize traffic control and may offer sidecarless options by focusing more on centralized gateways.
Difference from Istio: Kuma is more centered around its gateway approach and isn’t necessarily a direct competitor in the same sidecarless architecture. Istio’s sidecarless approach is more focused on evolving its existing powerful traffic management (Envoy) to a more efficient architecture.
Key Distinctions for Istio Sidecarless
- Leveraging Envoy still: Istio’s sidecarless approach may still rely on Envoy proxies but deployed in a more centralized or node-level manner. Other service meshes like Cilium focus on bypassing proxies entirely by using eBPF.
- Familiarity and maturity: Istio sidecarless retains the strengths of the Istio control plane, offering mature traffic management and advanced features that are well-established in the industry, while sidecarless models from newer solutions may be more experimental or niche in certain environments.
Why Istio Sidecarless?
The movement towards a sidecarless architecture is largely driven by the desire to:
- Reduce resource overhead: Sidecars consume extra CPU, memory, and networking resources, which can be a burden in large-scale environments.
- Simplify operations: Without needing to deploy and manage sidecars for each service, operations teams can reduce complexity.
- Increase performance: Reducing network hops between service containers and sidecars helps reduce latency.
Ultimately, Istio Sidecarless is a way to improve the operational model of Istio while retaining its powerful traffic management capabilities.