OpenYurt v0.7.0 Interpretation: Raven, A Non-intrusive Cross-Network Domain Solution

By Chen Jinci and He Linbo

OpenYurt v0.7.0 was released on May 27, 2022.

The new version mainly released the Raven solution. It solves the communication problem between pods at the edge and edge across the public network without being intrusive to the native container network solution. It meets the demands of the container network in the cloud-edge collaboration scenario. OpenYurt v0.7.0 also supports the LTS version (Jakarta) of EdgeX Foundry and the K8s version v1.22.

Non-Intrusive Solution for Cross-Edge Container Networks in a Single Cluster

OpenYurt clusters provide single-cluster container network connectivity across the public network edge-to-edge and edge-to-cloud. Its main technical principle is to enable container networks on different edge nodes to connect through encrypted public network tunnels, thus realizing cross-edge business traffic or controlling traffic communication. It is compatible with the current mainstream container network solutions (such as flannel and calico), which means the communication in NodePool still uses the native container network solution.

Background

Edge-to-edge and edge-to-cloud communication are common network communication scenarios in edge computing. We have introduced YurtTunnel for the OpenYurt project to deal with the network issues of O&M and monitoring in edge-cloud collaboration. It allows you to execute kubectl exec/logs on edge nodes and obtain monitoring metrics from them. However, the problem that YurtTunnel solves is only a subset of edge-to-cloud communication. Before v0.7.0, there was no solution for edge-to-edge and edge-to-cloud container network communication.

In some cases, pods in different physical regions in an OpenYurt cluster may need to communicate with other pods using Pod IP, Service IP, or Service Name. Although these pods are in a single Kubernetes cluster, they cannot communicate if they are in different physical regions (network domains).

Design Concept and Architecture

The Raven project is based on the collaboration of the open-source community, including requirement discussion, scheme design, and final implementation. The overall design concepts include:

No Intrusion: No intrusion to the native Kubernetes CNI network, only hijacking cross-edge traffic for forwarding.
It can work seamlessly with mainstream container network solutions (such as flannel and calico).
High Security: It ensures data security across the public Internet.

The following figure shows the architecture of the Raven solution:

Raven Controller Manager: It is a standard Kubernetes controller, which is deployed in some cloud nodes as a Deployment, and monitors the status of edge nodes. It selects an egress of cross-edge traffic for each edge node pool as the gateway node and can switch the gateway node when the current gateway node is deactivated. All cross-edge traffic is forwarded by the gateway node of each edge node pool.
Raven Agent: It is deployed in DaemonSet mode and runs on each node of the cluster. It configures routing information or VPN tunnel information on the node according to the role (gateway or non-gateway) of each node.

The preceding two components use a Gateway CRD to exchange the necessary information for configuring routes and establishing a VPN tunnel, as shown in Figure 2.

Please refer to the project code warehouse for more details:

Raven Controller Manager: https://github.com/openyurtio/raven-controller-manager
Raven Agent: https://github.com/openyurtio/raven

Features

No Intrusion: It gives no intrusion to the native Kubernetes CNI network, which means traffic in the same edge node pool is not hijacked, and the CNI capabilities of the cluster are reused.
Secure and Reliable: It uses mature and stable IPsec technology to encrypt cross-edge traffic.
Perfect Compatibility: It can work seamlessly with mainstream container network solutions (such as flannel and calico).
High Performance: Raven will use the network capabilities of the edge itself to create an edge-to-edge VPN tunnel as much as possible in the processing of cross-edge traffic and will not forward all cross-edge traffic through the cloud center.

Support EdgeX Foundry LTS Version

EdgeX Foundry Jakarta is the first LTS version and is widely regarded as a product version. Support for EdgeX Foundry Jakarta versions has been completed in OpenYurt v0.7.0. Since the EdgeX Jakarta version is switched to API v2, OpenYurt optimizes the adaptation logic with EdgeX, and CRD is partially optimized. Please refer to [#30] for details.

Support Kubernetes v1.22

OpenYurt has done a lot to adapt to Kubernetes v1.22: v1beta1.CSR is removed from resources, and CSR.signerName is verified and updated. Each component in OpenYurt that applies for certificates has been adapted accordingly. At the same time, the Service Topology feature is adapted to requests for v1.EndpointSlice resources, and the YurtTunnel is adapted to remove StreamingProxyRedirects features. Please refer to [#809] for details.

Support IPv6 Network

The IPv6 network first requires CNI container network support. In OpenYurt, network configuration and certificate application are mainly involved in YurtHub and YurtTunnel. Please refer to [#842] for details.

Future Plans

OpenYurt v0.7.0 focuses on Raven, a cross-network domain solution. It also supports EdgeX Foundry LTS version, K8s v.122, IPv6 network, and others.

OpenYurt v0.8.0 is progressing steadily at the moment. The OpenYurt community has set up SIGs (such as ControlPlane, DataPlane, IoT, etc.) to support and collaborate with 15 + projects in the community. You are welcome to participate in the joint construction.

Please pay attention to this link for the roadmap of OpenYurt v0.8.0.