Leaf-to-Leaf Traffic Optimization for a "Central" Cluster Peered with Two "Edge" Clusters

[scal110]

Describe the solution you'd like

Overview
Currently, Liqo provides a mechanism to establish network connections between clusters using the liqoctl network connect command. However, this command must be executed from one of the participating (edge) clusters. We propose to enhance this functionality by creating a unified command that can be executed directly from the central cluster, thereby coordinating connections between two edge clusters. This unified approach would simplify the workflow and optimize leaf-to-leaf traffic.

Proposal
Unified Command for the Central Cluster
We propose the creation of a new command that:

Is executed from the central cluster.
This command will be available on the main (central) cluster, addressing the current limitation where liqoctl network connect can only be executed on one of the edge clusters.
Combines network initialization and connection.
It will merge the functionality of liqoctl network init (which sets up all necessary network configurations) and liqoctl network connect (which establishes the connection) into one unified operation.
New Custom Resource and Operator
In addition to the unified command, we propose introducing a new Custom Resource (CR) (e.g., VirtualNodeShortcut) and a corresponding operator that will:

Manage the Lifecycle of Direct Connections:

The operator will watch for the creation or updates of the VirtualNodeShortcut CR and trigger the unified command to initialize the network and establish a direct connection between the two edge clusters.
Configure Network Parameters:

The CR will define the necessary parameters, including references to the kubeconfigs (or credentials) for both edge clusters, IP mapping policies, and any specific settings related to gateway configuration.
The operator will use these parameters to generate the correct configuration for the connection, ensuring that offloaded pods in the edge clusters can communicate directly via a dedicated gateway rather than through the central cluster's externalCIDR.
Optimize Traffic Flow:

By enabling direct leaf-to-leaf traffic, the proposal aims to reduce latency and central cluster load. Traffic between pods on different edge clusters will bypass the central cluster entirely.

Describe the user value of this feature

Benefits
Centralized Control:
With the unified command available on the central cluster, network connections can be initiated and managed centrally, simplifying operations and administration.

Improved Performance:
Direct communication between edge clusters minimizes latency and reduces unnecessary hops through the central cluster.

Simplified Workflow:
Administrators no longer need to execute separate commands on different clusters. A single command from the central cluster will initialize and connect the network, providing a more streamlined experience.

Consistent Configuration:
The new CR will ensure that all necessary configuration details (such as IP mappings) are defined in one place, leading to fewer configuration errors and a more robust connection setup.

By introducing a unified command for network initialization and connection, executed from the central cluster, we can significantly simplify the process of establishing direct leaf-to-leaf connections. This will lead to improved performance, reduced latency, and better manageability of network connections in multi-cluster environments. The accompanying CRD and operator will provide a declarative and centralized way to configure and manage these connections, ensuring consistency and reliability in the network offloading process.

Describe your proposed solution

No response

Do you volunteer to implement this feature?

• I want to implement this feature

Code of Conduct

• I agree to follow this project's Code of Conduct