English | 简体中文
EdgeMesh, as the data plane component of the KubeEdge cluster, provides simple service discovery and traffic proxy functions for applications, thereby shielding the complex network structure in edge scenarios.
KubeEdge is build based on Kubernetes, extending cloud-native containerized application orchestration capabilities to the edge. However, at the scenario of edge computer, the network topology is more complex. Edge nodes in different areas are often not interconnected, and the inter-communication of traffic between applications is the primary requirement of the business. For this scenairo, EdgeMesh offers a solution.
EdgeMesh satisfies the new requirements in edge scenarios (e.g., limited edge resources, unstable edge cloud network, complex network structure, etc.), that is, high availability, high reliability, and extreme lightweight:
- High availability
- Use the capabilities provided by LibP2P to connect the network between edge nodes
- Divide the communication between edge nodes into intra-LAN and cross-LAN
- Intra-LAN communication: direct access
- Cross-LAN communication: when the hole punching is successful, a connection channel is established between the Agents, otherwise it is forwarded through the Server relay
- High reliability (offline scenario)
- Both control plane and data plane traffic are delivered through the edge cloud channel
- EdgeMesh internally implements a lightweight DNS server, thus no longer accessing the cloud CoreDNS
- Extreme lightweight
- Each node has one and only one Agent, which saves edge resources
User value
- Enable users to have the ability to access edge-to-edge/edge-to-cloud/cloud-to-edge applications across different LANs
- Compared to the mechanism of CoreDNS + Kube-Proxy + CNI service discovery, users only need to simply deploy an Agent to finish their goals
| Feature | Sub-Feature | Realization Degree |
|---|---|---|
| Service Discovery | / | ✓ |
| Traffic Governance | HTTP | ✓ |
| TCP | ✓ | |
| Websocket | ✓ | |
| HTTPS | ✓ | |
| Load Balance | Random | ✓ |
| Round Robin | ✓ | |
| Session Persistence | ✓ | |
| Edge Gateway | External Access | ✓ |
| Multi-NIC Monitoring | ✓ | |
| Cross-Subnet Communication | Cross-Cloud Communication | ✓ |
| Cross-LAN E2E Communication | ✓ | |
| Edge CNI | Cross-Subnet Pod Communication | + |
Noting:
✓Features supported by the EdgeMesh version+Features not available in the EdgeMesh version, but will be supported in subsequent versions-Features not available in the EdgeMesh version, or deprecated features
The above figure shows a brief overview of the EdgeMesh architecture, EdgeMesh contains EdgeMesh-Server and EdgeMesh-Agent.
The core components of EdgeMesh-Server include:
- Tunnel-Server: Based on LibP2P, establish a connection with EdgeMesh-Agent to provide relay capability and hole punching capability
The core components of EdgeMesh-Agent include:
- Proxier: Responsible for configuring the kernel's iptables rules, and intercepting requests to the EdgeMesh process
- DNS: Built-in DNS resolver, which resolves the DNS request in the node into a service cluster IP
- Traffic: A traffic forwarding module based on the Go-Chassis framework, which is responsible for forwarding traffic between applications
- Controller: Obtains metadata (e.g., Service, Endpoints, Pod, etc.) through the Local APIServer capability on the edge side of KubeEdge
- Tunnel-Agent: Based on LibP2P, using relay and hole punching to provide the ability of communicating across subnets
Before using EdgeMesh, you need to understand the following prerequisites at first:
- while using DestinationRule, the name of the DestinationRule must be equal to the name of the corresponding Service. EdgeMesh will determine the DestinationRule in the same namespace according to the name of the Service
- Service ports must be named. The key/value pairs of port name must have the following syntax: name: <protocol>[-<suffix>]
Documentation is located on netlify.com. These documents can help you understand EdgeMesh better.
Follow the EdgeMesh installation document to install EdgeMesh.
Example1: HTTP traffic forwarding
Example2: TCP traffic forwarding
Example3: Websocket traffic forwarding
Example4: Load Balance
Example5: Cross-edge-cloud communication
If you need support, start with the 'Operation Guidance', and then follow the process that we've outlined
If you have any question, please contact us through the recommended information on KubeEdge
If you are interested in EdgeMesh and would like to contribute to EdgeMesh project, please refer to CONTRIBUTING for detailed contribution process guide.