## 4 Implementing L2S-M in a Cloud-Native Platform for Intra-Site Connectivity: K8s Case  
### L2S-M Implementation as a K8s Operator  
This subsection introduces an implementation of L2S-M as a K8s operator, enabling the creation and management of a virtual network in a distributed K8s infrastructure to securely communicate workloads at the link-layer level. Although this subsection focuses on the intra-site implementation of L2S-M, the validation present in this paper will showcase the basic functionality of inter-cluster communications (described in the previous section) to demonstrate its functionality in those scenarios. Figure 3 depicts the detailed implementation of the full L2S-M solution in a K8s cluster. This implementation contemplates the deployment of all the components depicted in Figure 2 with their respective particularities to allow functionality inside a K8s cluster since the implementation of this solution is not a straightforward task due to the complexity that pod namespace isolation and API model introduce in K8s. First of all, L2S-M requires the deployment of a set of L2 switches over the K8s infrastructure, as it is showcased in Figure 2. These switches are necessary components to enable the establishment of the L2 overlay required to exchange data between pods. However, instead of directly installing the switch in the node itself, L2S-M relies on the advantages that K8s provides (containerisation, automatic deployment, life-cycle management, etc.) to deploy each switch as a pod on every node of the cluster. Particularly, L2S-M uses a \"daemonset\" (a K8s resource that deploys one pod per node in the cluster) that installs an open virtual switch (OVS) in the node. Although any L2 switch solution can be used for this purpose, L2S-M uses OVS due to its compatibility with multiple OS and distributions, as well as its simplicity for its installation and configuration. Once the switch infrastructure is available in the K8s cluster, it is necessary to deploy point-to-point links between the desired neighbouring nodes to enable link-layer connectivity between each other through IP tunnelling mechanisms, as showcased in the design and in Figure 2. Instead of building a mesh with all the members of a K8s cluster (a common practice in CNI plugin solutions), each programmable switch is only interconnected to the desired peer, which can either be a virtual switch or a physical one. The figure depicts these connections (thick blue links between V-SWs) performed using VXLAN tunnels, although any IP tunnelling mechanism can be used (for instance, GRE [40]). L2S-M must be able to create this overlay as well. However, having the switches containerised introduces a problem, as it can be seen in Figure 3: the pods are not able to reach the other nodes directly since they are located behind their own namespace inside the node, so directly building an IP tunnel with the node would not work, or it would be necessary to use the CNI plugin for the standard K8s networking (which follows the flat networking approach and is incompatible with the concept of the solution). To avoid this struggle, L2S-M builds the VXLAN tunnels beforehand in the host namespace (since they must be able to see other at the IP layer, as a requirement of the K8s cluster), either using a dedicated interface for this purpose or its main interface. Afterwards, L2S-M \"moves\" these tunnel interfaces into the switch pod using the Multus CNI plugin since this plugin enables to bring the pre-created VXLAN interfaces into the OVS pod without losing the link-layer configuration. Regardless of the containerisation of the switches, it is necessary to enable the attachment of the pods with the switches of the overlay deployed in every node in order to perform the data exchange between other pods. However, every pod is located in its own namespace, so connectivity between the pods and their (virtualised) switch cannot be directly established (as it can be seen in Figure 3).