## 4 Implementing L2S-M in a Cloud-Native Platform for Intra-Site Connectivity: K8s Case
### L2S-M Implementation as a K8s Operator
To overcome this problem, a virtual Ethernet (vEth) element can be used to exchange messages between each namespace, as it mimics a \"real\" Ethernet cable, where packets sent at one end of the vEth appear at the other end, regardless of the namespaces at which they are located. L2S-M builds a set of vEth pairs in the host namespace, and then L2S-M attaches one extreme to the switch, leaving the remaining one in the host namespace. Once a pod desires to connect to a virtual network, L2S-M uses the Multus plugin to attach the other end into the pod, effectively connecting these two elements (just as it is done in a physical switch):  
Figure 3: L2S-M implementation in a K8s infrastructure. when a packet is generated inside the pod, the vEth will forward the packet into the Linux Kernel, and the packet will be forwarded to the switch. However, K8s does not have the tools to deal with the definition and management of virtual networks on demand, or allowing the assignment of the corresponding vEth pairs in each one of the hosts to the workloads deployed in the cluster. This is where a key element in the L2S-M design comes into play: the L2S-M K8s operator. A K8s operator [44] is a software extension to Kubernetes that allows the management of custom resources in a K8s cluster, which might contain any information and can only be used by coordinating the K8s API events with the operator to perform certain actions or events in the cluster. The L2S-M K8s operator takes advantage of a pre-existing CustomResourceDefinition (i.e., resources that are not native to the K8s environments) (CRD) from Multus (the well-known NetworkAttachmentDefinition (NAD)) to define the virtual networks that we want to create in a cluster. If we want a pod to be added into one of these virtual networks, it will be written in its metadata in the same fashion as it would be done in a standard Multus definition (a common standard in real K8s deployments). However, these are not mere Multus annotations since they must be managed by an element that is able to identify which pods want to belong to which virtual networks, as well as to perform the necessary actions to attach the ports of each switch into the pod. Therefore, L2S-M includes the definition of the L2S-M operator, which is an agent (deployed as a pod) that is deployed in a controller node of a cluster as it can be seen in Figure 3. This pod will constantly monitor the calls between the K8s API, picking up several events that occur within the cluster. Depending on the type of event that is picked up by the operator, it will perform a different action. In this fashion, the L2S-M operator will be triggered when a \"creation event\" with a NAD is registered from the K8s API to check if the corresponding resource is a virtual network or a standard Multus definition (in such a case, the operator will not perform additional actions). If it is a virtual network, it will register its creation in the cluster, writing this network in its database (L2S-M DB). After the creation of a virtual network, once a pod starts its deployment in a cluster, it will generate a creation event and, if the pod being generated includes a NAD annotation in its metadata, the operator will begin to process this annotation prior to its deployment. The operator will then identify each one of these annotations to see if the pods express their desire to be attached into one, or several, virtual network(s), checking if any of the networks created in the cluster are present. If not, the operator will let Multus handle the deployment. Otherwise, the operator will retrieve the node where the pod is going to be deployed, and will check if there are available interfaces (i.e., free vEth ends) in the host namespace. Once a vEth is selected, the operator will assign that interface to the pod and register that it belongs to a particular virtual network.