Integration of Liqo v1.0.0-rc.3

[andreacv98]

Hello everyone,

With this PR I am updating the Liqo version from v0.10.3 to v1.0.0-rc.3.

What changes will you see?

TLDR: everything will be exactly the same as before, except for the liqoctl tool version, which must now be at least v1.0.0-rc.3.

Long answer: The integration of the Liqo version mainly affected the peering feature of the Virtual Fabric Manager (part of the Rear Manager). All new resources to create a manual peering in Liqo v1.0.0-rc.3 are inside this function, but at the end you will always have the VPN channel through Wireguard, the foreign clusters and most important: the namespace offloadings and the virtual nodes.
The breaking change, user side, is to use the version of the liqoctl tool updated to v1.0.0-rc.3 and the new commands to check the liqo peering "liqoctl info peer" (not compatible with old liqoctl versions).

What if you use low-level Liqo resources directly?

If you use resources such as namespace offloads or interact with virtual nodes through automated processes, you need to update your Liqo dependency to v1.0.0-rc.3. Fortunately, these resources haven't changed much, but be aware of changes in labels or specific fields in the specs and status of these resources.

No problem if you use the liqoctl tool to offload the namespace and interact with Liqo, everything should be pretty much the same.

Breaking changes in the Fluidos node

Setup script

The setup script for testing the node within KinD has been updated to use the new Liqo version, it should detect if you have the liqoctl v1.0.0-rc.3 installed locally, otherwise it will automatically install it in a tmp folder (so as not to damage or replace your currently installed stable version of liqoctl).
If you want to use the liqoctl downloaded, compiled and used by the script, you can find it (temporarily) in /tmp/liqo/liqoctl.

Foreign Cluster Interaction

Previously the foreign cluster was the starting point of our peering function, it was enough. In the new version of Liqo, the foreign cluster is something that is automatically created by Liqo once all the various steps of manual peering have been completed (network setup, authentication, offloading). The allocation controller still watches the resources of the foreign cluster, but only as an informer about the status of the peering.

Liqo Peering Phases

The Liqo v1.0.0-rc.3 manual peering has three main phases to set up peering. I won't go into detail, but roughly the same steps are reproduced in the Virtual Fabric Manager module, and they are performed in a similar way, trying to use the Liqo library as much as possible.

How peering is done

The Liqo v1.0.0-rc.3 does not support the old way of creating a token and exchanging it with the consumer, now they need to exchange a kubeconfig. In the same way, we reproduce this step, creating a kubeconfig, with the minimum permissions for the consumer to just create the various Liqo resources to establish peering, both locally and remotely. This is something that can definitely be improved (by carefully removing the service account generated once the peering has been established, exchanging only the data to create the various resources on both clusters, etc.), but with this first integration I evaluated to just keep it simple enough to test if Liqo v1.0.0-rc.3 was suitable inside the Fluidos node.

This data replaces the token previously exchanged via REAR to perform this kubeconfig exchange. Therefore, the field name and meaning may have changed (only the token). However, the protocol and its workflow are exactly the same as before.

Removing the GRPC server

Previously we had the GRPC server running inside the Rear Controller component, which was responsible for telling Liqo the exact amount of resources to allocate for a given peering. This component is no longer supported because in the offloading phase you create a custom resource slice (Liqo resource) that owns this data. In this version of the integration, I decided to just write the amount of resources to look in the contract, but the resource slice needs to be created by the consumer, so the one who buys the resources. An experienced user can simply edit these resources applied by the rear manager in the peering phase and get more than what was agreed.
This can be fixed by editing the resource slice to a custom "class" (spec of the resource slice) and on the provider side, a controller can watch for this resource slice on specific class and populate its resources according to the contract that the provider owns by its side.

So this is a known issue, with an ideal solution to be implemented, but at the moment the purpose of this PR is to test the Liqo v1.0.0-rc.3 integration.

---

I hope this contribution will be appreciated and tested. Once tested through this specific branch, I would suggest to move it to the main branch and release it carefully, maybe through a release candidate first to check if everything works.

Feel free to give me feedback.

Thanks a lot!

Andrea