Feb 2
Exploring Service Mesh through Istio, eBPF, and RSocket Broker: An In-depth Study.
Introduction:
In today’s fast-paced world of technology and in the microservice era, the complexity of governing services has risen due to more business responsibilities being tied to them.
Merely relying on framework-level governance is insufficient, and a comprehensive governance system is necessary.
This article examines service governance through multiple perspectives and provides an understanding of Service Mesh, Istio, eBPF, and RSocket Broker by exploring traditional and modern approaches.
1. Service governance
Governance refers to processes for establishing and enforcing how microservices work together to achieve the business objectives for which the system was designed and built.
Governance of services can be achieved in multiple ways:
- Service registration and discovery: Consul, ZooKeeper
- Service configuration: Spring Cloud Config
- Load balancing: Ribbon, Feign
- Tracking tools: Sleuth, Zipkin
- Monitoring: Grafana, Prometheus
Later on, we will discuss a few of them.
Service registration and discovery
Nowadays, single large monolith applications are broken up into smaller individually deployable units referred to as microservices.
When a service communicates with another, it needs the IP and port of the remote end. Keeping this information in a config file is simple, but it doesn’t allow for cloud scalability since server instances cannot be adjusted based on load with this method.
Service Discovery addresses this issue by allowing services to register themselves with their IP and port in a service registry for clients to access. Health checks also ensure traffic is only forwarded to healthy instances.
Load balancing
Load balancing distributes network requests among multiple servers to increase processing capacity. We’ll examine using RSocket to balance client requests across server pools.
2. Sidecar Pattern
Sidecar mode divides application functions into separate processes within the same unit. It reduces code repetition and complexity by allowing non-business logic functions to be abstracted. Sidecar containers can be used to handle concerns such as observability, monitoring, logging, configuration, and circuit breakers, in a Kubernetes Pod.
In sidecar mode, proxy containers share network namespace with app containers in a Pod, providing isolated network stacks. This allows multiple pods to run a web application on port 80, with the proxy intercepting traffic to and from the app container.
3. A trip to Service Mesh
The microservice architecture enables multiple units with single responsibilities to form a complex application.
Early microservices relied on internal SDK for service discovery, retry, etc., leading to drawbacks like increased software stack, reliance on specific language, high upgrade/deployment costs, and a learning curve. Business logic and non-functional code being coupled also resulted in frequent application releases with newer versions, even if business logic remained unchanged.
Service Mesh
Service Mesh is an infrastructure layer used to handle communication between services through the sidecar mode providing secure, fast, and reliable inter-service communication in the form of a transparent proxy.
With Service Mesh, microservice capabilities are removed from the application and housed in sidecar containers. This allows the microservice to focus solely on business logic while the infrastructure team manages general capabilities, resulting in efficient independent evolution.
Istio and Linkerd are popular open-source Service Mesh options with a simple architecture consisting of a control plane and a data plane.
The data plane intercepts service calls while the control plane manages coordination and versioning. Services communicate through local sidecar agents instead of directly through the network.
4. A quick tour of Istio
Istio is an open platform for service governance in the Service Mesh form for cloud-native scenarios that is closely integrated with Kubernetes.
Istio provides load balancing, authentication between services, monitoring, and other functions.
Istio Architecture
The architecture of Istio is divided into a control plane and a data plane.
- Data plane: It consists of sidecar agents throughout the grid, which is deployed in the form of sidecars together with application services. Each sidecar will take over the flow in and out of the service, and cooperate with the control plane to complete functions such as traffic control.
- Control plane: As the name implies, it controls and manages sidecar agents in the data plane, and completes configured distribution, service discovery, authorization authentication, and other functions. Core components
Let’s briefly introduce the main functions of several core components in the Istio architecture.
Envoy
Envoy is a high-performance C++ agent used in Istio service mesh as a sidecar container that intercepts all inbound and outbound traffic, performs functions like load balancing, circuit breaking, and fault injection, and provides metrics collection for Prometheus and Jeager. It is part of the data plane in Istio.
Istiod
Istiod is a control plane component to providing service discovery, configuration, and certificate management functions. Istiod adopts advanced rules written by YAML and converts them into an actionable configuration of Envoy. It then propagates this configuration to all sidecars in the grid.
- Pilot The main function of the Pilot component is to convert configuration information such as routing rules into information that can be recognized by the sidecar and sent to the data plane. It can be simply understood as a configuration distributor and assisting sidecar to complete traffic control-related functions.
- Citadel: Citadel is a security component in Istio that generates certificates to allow secure mTLS communication between agents in the data plane.
- Galley: Galley is a new component in version Istio 1.1, which aims to decouple Pilot and underlying platforms such as Kubernetes. It shares part of the original Pilot’s functions and is mainly responsible for the verification, extraction, and processing functions of the configuration.
Istio traffic forwarding
Traffic routing is divided into Inbound and Outbound processes.
SideCar by Istio + Envoy is a popular Service Mesh architecture that injects the Envoy agent as a sidecar container to intercept all traffic to/from the main container, providing features such as load balancing, fault injection, and metrics collection.
However, there are considerations such as performance degradation, architectural complexity, and increased operational costs. An init container is used to set network rules, but adding a proxy increases resource usage and requires an automated operation setup, typically using Kubernetes.
5. Overview of eBPF technology
Using a sidecar mode, as you may have already observed, we need to deploy a container on each unit with a proper configuration. If you take a closer look, each node has only one kernel; all containers running on one node share the same kernel, can’t we leverage this to shrink the number of deployed sidecar proxies to the number of nodes? This leads us to eBPF.
eBPF is a kernel technology that enables the running of custom programs in response to various events, including network packets, function access, and others.
This technology reduces the number of deployed sidecar proxies in the service grid by allowing custom programs to be run directly on the host, without the need for a sidecar. eBPF-driven solutions can provide observability, security, and network benefits without the need for a sidecar container on each unit.
On December 2nd, 2021, the Cilium project announced a beta testing program for Cilium Service Mesh. The eBPF-based Cilium project brings this “sidecarless” model to the world of a service mesh to handle much of the sidecar proxy functionalities in a service mesh, including L7 routing, load balancing, TLS, access policies, health checks, logging, and tracing.
What do we gain by switching to this new mode?
YAML reduction
In the sidecar model, YAML must be modified to add a sidecar container for each pod but failing to correctly label the namespace or Pod can result in the sidecar not being injected.
The sidecar-free proxy model that supports eBPF can detect pods without modification and includes them in the service grid, allowing for the detection of malicious activity even if an attacker circumvents Kubernetes orchestration. Additionally, eBPF-enabled networking improves performance by bypassing some kernel network stacks.
Network efficiency
In eBPF-enabled networking, packets can bypass some network stacks of the kernel, which can improve performance. Let’s see how this applies to the service grid data plane.
In the eBPF acceleration and sidecar-free service grid model, the path of network packets passing is much shorter.
In a service grid, the packet path to the application is long and results in increased latency.
Cilium, a Kubernetes CNI based on eBPF, can use eBPF to redirect packets to a more direct route and minimize latency. The service grid is usually used for authentication and encryption of application traffic through bidirectional TLS (mTLS) or network layer encryption with IPSec or WireGuard.
Network layer encryption is a simpler and more versatile option for encryption as it applies to all traffic on nodes, not just workloads with sidecar enabled.
6. RSocket Broker
RSocket routing broker is a communication system between a wide range of applications using RSocket protocol.
An RSocket Broker works as follows: A service caller (Requester) initiates a service call request to the broker, the broker forwards the request to the service provider (Responder), and the broker ultimately returns the responder’s processing results to the requester.
In a service-based architecture, the communication between service providers and consumers is facilitated by a central entity known as the Broker.
When a service provider starts, it establishes a persistent connection with the Broker and informs it of the services it can offer. On the other hand, when a service consumer starts, it also connects to the Broker.
When a consumer needs to access a remote service, it sends a message to the Broker, which acts as an intermediary. The Broker receives the message and uses the meta-information to parse the desired service. It then consults its routing table to find a suitable service provider.
The selected service provider processes the request and sends back a message to the Broker with the result. The Broker then forwards the message to the original service consumer. The consumer receives the response and performs the appropriate business logic.
This Broker-based message communication method has the following advantages:
- No third-party health check is needed as we know when a connection is up
- No port listening: The service provider no longer listens on the port, which is completely different from the HTTP REST API and gRPC, which is more secure
- Communication transparency: The requester and the service provider do not need to perceive the existence of each other
- Service registration and discovery: No need for third party registry, such as Eureka, Consul, ZooKeeper, etc., reducing infrastructure dependency costs
- Security: The broker will verify the access rights of service providers and service consumers, and only need to deploy TLS support on Broker to ensure the security of communication channels
No easy gains
There are a few drawbacks to using the Broker as well. One issue is that performance may be slightly affected as direct communication between parties is not possible. Another is that all communication traffic passes through the Broker, creating a potential bottleneck in the network. However, this can be reduced by having a highly reliable cluster and Broker.
7. Service governance through RSocket Broker
As a Service Mesh solution, Istio is difficult to apply outside a data center. what about IoT devices? Install a sidecar on every mobile phone? This is where the RSocket broker comes into the picture.
RSocket routing broker can be used to implement Service Mesh. In the scheme below, there’s no sidecar running and no duplication of processes.
Here is a comparison of the typical characteristics of the two architectural schemes:
- Infrastructure layer: On one side it’s a sidecar proxy + control plane, and the other is a centralized broker with integrated control plane functions.
- Centralized management: Centralization will make management more comprehensive, such as Logging, Metrics, etc.
- Communication protocol: One drawback of the RSocket scheme is that the RSocket communication protocol must be used between applications.
- Efficiency: RSocket protocol performance is 10 times higher than HTTP.
- Security: RSocket security is simpler, relying on TLS + JWT, reducing the attack surface and offering easier fine-grained permission control.
- Network and infrastructure dependency: RSocket Broker has an advantage over Istio as it does not rely on Kubernetes, while Istio still requires a deployment and management of sidecar proxies within or outside of Kubernetes, which is not straightforward. RSocket Broker can be deployed anywhere without network or infrastructure dependency.
Conclusion
Service governance is a very important growing topic in the microservice era. We looked at different ways to implement it, through Istio, eBPF, and RSocket Router.
