The Liqo resource replication model is made by a set of components that replicate each resource with an object-specific logic. One important example is represented by namespaces. More precisely, namespace replication across multiple clusters implements a core mechanism to seamlessly extend a cluster to some others.
In the Liqo model, the namespace replication operates on a standard v1.Namespace, associated with a Liqo-specific NamespaceOffloading CR; this new CR allows to specify the remote clusters on which the application can be scheduled.
Section Namespace Extensions shows how to define and use a NamespaceOffloading resource that enables the replication of the local namespace on peered clusters.
This section shows how the Liqo namespace model works under the hood, understanding which resources and controllers are activated when a new NamespaceOffloading is manipulated.
Liqo namespace replication involves instances of two kinds of CRDs:
The namespace replication logic is performed by several controllers responsible for different aspects of this process:
The figure below figures out the overall workflow steps of the replication process:
The mechanism can be resumed in the following steps:
When the user creates a NamespaceOffloading object in a Liqo-enabled namespace (Step 1 in the figure), the Liqo logic processes the resource spec. After having detected the virtual nodes compliant with the NamespaceOffloading selector, the NamespaceOffloading controller fills the NamespaceMap resources of the selected nodes. More precisely, the controller sets the creation requests in the DesiredMapping spec field of the various NamespaceMap resources (Step 2 in the figure). This logic is recalled every time a new virtual node joins the topology to check if it is compliant with the NamespaceOffloading selector.
Once the NamespaceOffloading controller has filled the NamespaceMap with the requests, the NamespaceMap controller should enforce the remote namespaces’ creation. The operations outcome is saved in the CurrentMapping status field (Step 3 in the figure). The NamespaceMap Controller periodically checks if each entry in the DesiredMapping spec field has an associated remote namespace. In case of absence, it immediately enforces a new namespace creation. Furthermore, the controller performs health probes on these namespaces. Whenever it detects a change in the namespaces state, it immediately updates the NamespaceMap resources.
The OffloadingStatus Controller is responsible for the NamespaceOffloading status reconciliation (Step 4 in the figure). It periodically checks the status of all NamespaceMaps in the clusters, and for each NamespaceOffloading object, it updates the RemoteNamespaceConditions and the OffloadingPhase fields. As already detailed in the NamespaceOffloading status description, these fields provide the user with all the information about the replication process (Step 5 in the figure).
The following figure provides an example of this mechanism:
The steps represented are the same as described above. More precisely, the constraints specified in the NamespaceOffloading require the creation of a remote namespace only on the regionB-cluster. Consequently, only the corresponding NamespaceMap will be updated.
The deletion mechanism can be summarized in these core steps:
When the user decides to delete the NamespaceOffloading resource, the termination of the replication process starts, and the OffloadingStatus controller sets the OffloadingPhase field to Terminating.
The NamespaceOffloading controller removes all the entries associated with that resource from the DesiredMapping field of the NamespaceMap objects.
The NamespaceMap controller reacts to this event enforcing the deletion of all the remote namespaces no longer required. In particular, when a remote namespace is deleted, it removes the corresponding entry from the NamespaceMap CurrentMapping field.
When the NamespaceMap controller removes an entry from the CurrentMapping field of one NamespaceMap resource, the OffloadingStatus controller deletes the remote conditions associated with that namespace in the NamespaceOffloading resource. Once all the remote namespaces have been removed and, therefore, all associated remote namespace conditions, then the NamespaceOffloading resource is finally removed, and the deletion process is complete.