ARK – Virtual continuum library
| ID: R14 | Licence: Apache License V2.0 |
Owner: Liqo: Liqo Maintainers Node Binding Module: ARK |
Contacts: luca.castello@arubakube.cloud giuseppe.zangari@arubakube.cloud francesco.cheinasso@arubakube.cloud francesco.torta@arubakube.cloud |
| Short Description | Liqo is an open-source project enabling seamless Kubernetes multi-cluster management, allowing resource sharing and collaboration across diverse Kubernetes environments. In MYRTUS it federates the Kubernetes clusters of the edge, fog and cloud layers, across different sites and administrative domains, into a single computing continuum. The MYRTUS Node Binding Module complements it, so that workloads can be placed on a specific node of a remote cluster. | |
| Liqo | Node Binding Module | |
|---|---|---|
| Key features | – Multi-cluster federation: cluster-to-cluster peerings for resource sharing and workload distribution across Kubernetes environments – Remote clusters represented as virtual nodes, usable by the standard Kubernetes scheduler – Namespace offloading: selected namespaces are extended to peered clusters – Secure inter-cluster networking through WireGuard-based encrypted tunnels – Each cluster keeps its own control plane and administrative autonomy | – Targeting of a specific node within a Liqo virtual node – Precise workload placement, especially in edge clusters (e.g. on FPGA-based nodes) – Kubernetes module, used together with standard node affinity |
| Require | – Kubernetes cluster with version >= 1.20 – Cloud or on-premise environment supporting Kubernetes – Networking plugins (e.g. Calico, Cilium) compatible with Liqo – Network reachability between the clusters (WireGuard endpoints) | Liqo federation between the clusters. |
| Provide | – Transparent resource sharing between clusters – Deployment of applications across distributed infrastructures – Secure communication between workloads on different clusters | Binding of a workload to the actual target node in the remote cluster. |
| Input | – Kubernetes cluster configurations, including node details, namespaces and policies – Networking setup for inter-cluster communication – Application resource requirements | Workload placed on a Liqo virtual node, with the identifier of the target node in the remote cluster. |
| Output | – Integration and management of multiple Kubernetes clusters – Resource sharing across clusters – Federated namespaces for distributed applications | Workload executed on the selected physical node of the remote cluster. |
| User | – Platform engineers: multi-cluster management and resource sharing – Cloud architects: hybrid and multi-cloud architectures – DevOps teams: deployment scalability and resiliency | Orchestrators that need to place workloads on specific nodes of federated clusters, such as the MIRTO Deployer. |
| Benefits for the user | – Cloud-to-cloud and cloud-to-edge federation of Kubernetes clusters – Unified management of multiple clusters as one infrastructure – Edge resources for latency-sensitive workloads, cloud resources for high-capacity tasks – Better use of underutilized cluster resources | Placement decisions can target the physical resources behind a virtual node, without changing the federation. |
| Download | github.com/liqotech/liqo | github.com/ArubaKube/myrtus-nodebind |
| Role in MYRTUS | Core enabler of the MYRTUS reference infrastructure: it connects the Kubernetes clusters of each layer and site, and gives the MIRTO Deployer the capability to execute workloads across clusters and layers. | Second step of workload placement in the MIRTO cognitive engine: after node affinity selects the virtual node, it binds the workload to the target node. |
| TRL@M0 | 2 | |
| TRL@M36 | 4-5 | |
General description
Liqo
Liqo is an open-source platform designed to enable Kubernetes cluster federation, allowing resource sharing and workload orchestration across cloud, on-premise and edge environments. By leveraging automated inter-cluster communication and secure networking, it simplifies the management of hybrid and multi-cloud architectures.
It allows computational resources to be shared dynamically across independent Kubernetes clusters, through workload offloading, namespace extension, inter-cluster networking and declarative federation management, while each cluster keeps its native Kubernetes management. Remote clusters are represented as virtual nodes in the local cluster: their capacity becomes visible to the local Kubernetes scheduler, and workloads can be scheduled on them with standard placement constraints. Namespace offloading extends selected namespaces to the peered clusters and propagates the resources needed to run the offloaded workloads, and peerings are secured with WireGuard-based encrypted tunnels.
Node Binding Module
A virtual node represents a whole remote cluster, so it does not reveal the physical node on which a workload will actually run, for example an FPGA-based agent of an edge cluster. The MYRTUS Node Binding Module (myrtus-nodebind) solves this: workload placement is performed in two steps, where node affinity selects the virtual node and the module binds the workload to the actual target node in the remote cluster. This separates resource selection and deployment from the underlying infrastructure, so that the same orchestration workflow can target local or remote resources.
MYRTUS Extension/Contribution
Liqo
In MYRTUS, Liqo serves as a key enabler for establishing a computing continuum across the cloud, fog and edge layers. With Kubernetes clusters at each layer and site, Liqo provides the MIRTO agent with the capability to orchestrate workload execution across clusters and layers, ensuring efficient inter-cluster resource sharing and simplifying the management of distributed workloads.
At the start of the project Liqo was in a prototypal stage, with minimal functionality and loosely defined interfaces. Within MYRTUS, the library underwent substantial refactoring and stabilization: interfaces were formalized, core features were hardened, and the codebase was modularized to support extensibility and to align with the architectural and integration requirements of MYRTUS.
Liqo is the federation layer of the MYRTUS reference infrastructure, which has been instantiated as two multi-site federations: one connecting edge, fog and cloud clusters of several partners through a central cluster, and a separate one, with its own privacy domain, for the Mobility scenario. The integration also produced practical guidance, for example on the placement of the network gateways, on the permissions needed to verify peerings, and on avoiding nested configurations.
Node Binding Module
The Node Binding Module has been developed within MYRTUS to connect the federation to the orchestration layer. The workload manager queries the Distributed Knowledge Base for the available resources and computes an allocation map; the Deployer generates the corresponding Kubernetes manifests, and the module makes sure that each workload reaches the node chosen by MIRTO, also inside remote clusters.
Technology Benefits and Innovations
Liqo hides the complexity of a multi-cluster infrastructure behind a unified, Kubernetes-native interface, while preserving the autonomy and the independent control plane of each cluster. This makes it possible to build a continuum across infrastructure layers, sites and administrative domains on top of the de facto standard for orchestration, without depending on a single provider stack. Processing can be kept close to the data at the edge and fog layers, the cloud layer remains available for larger computing and storage demands, and federation boundaries can be used to respect privacy constraints. The Node Binding Module keeps this abstraction while letting orchestration decisions reach the physical resources behind it.
Users
Platform engineers who need to simplify multi-cluster management and resource sharing; cloud architects designing and optimizing hybrid and multi-cloud architectures; DevOps teams improving the scalability and resiliency of their deployments; and developers of orchestration systems for the edge-fog-cloud continuum who need to place workloads on specific nodes of federated clusters.
Application Domains
Hybrid and multi-cloud infrastructures, and edge-fog-cloud continuum systems spanning several sites and organizations, where latency-sensitive processing must stay close to the data while high-capacity tasks run in the cloud, and where clusters owned by different parties must share resources while remaining independent.