**NOTE**: The current version of L2S-M utilizes an infrastructure of virtual switches based on [Open Virtual Switch (OVS)](http://www.openvswitch.org). The integration of physical switches is currently ongoing.
**NOTE**: The current version of L2S-M utilizes an infrastructure of virtual switches based on [Open Virtual Switch (OVS)](http://www.openvswitch.org). This implementation can be followed up in https://github.com/Networks-it-uc3m/l2sm-switch .
In L2S-M, a k8s node deploys a virtual SDN switch or is connected to a physical SDN switch. Virtual switches are interconnected through point-to-point links. These links are established using IP tunnels (based on VXLAN technologies). This way, SDN switches build an overlay network that interconnects all the K8s nodes. L2S-M uses an SDN controller to install forwarding rules on the virtual/physical switches. This way, data traffic among workloads is appropriately distributed through isolated virtual networks (i.e., the SDN controller instructs the switches which ports should be used to forward and/or block incoming/outgoing traffic).
In L2S-M, a k8s node deploys a virtual SDN switch or is connected to a physical SDN switch. Virtual switches are interconnected through point-to-point links. These links are established using IP tunnels (based on VXLAN technologies). This way, SDN switches build an overlay network that interconnects all the K8s nodes. L2S-M uses an SDN controller to install forwarding rules on the virtual/physical switches. This way, data traffic among workloads is appropriately distributed through isolated virtual networks (i.e., the SDN controller instructs the switches which ports should be used to forward and/or block incoming/outgoing traffic).
...
@@ -14,6 +14,6 @@ Specifically for K8s clusters, the element in charge of managing the creation, d
...
@@ -14,6 +14,6 @@ Specifically for K8s clusters, the element in charge of managing the creation, d
To provide isolation among virtual networks, the operator interacts with the SDN controller component to communicate which ports are associated with each virtual network, updating its status every time a pod is deployed/deleted. Using this information, the SDN controller injects the corresponding rules in the switches, forwarding and/or blocking traffic according to the virtual networks being used at each moment.
To provide isolation among virtual networks, the operator interacts with the SDN controller component to communicate which ports are associated with each virtual network, updating its status every time a pod is deployed/deleted. Using this information, the SDN controller injects the corresponding rules in the switches, forwarding and/or blocking traffic according to the virtual networks being used at each moment.
**NOTE**: The current version of L2S-M utilizes a simple-switch implementation based on the [RYU](https://ryu.readthedocs.io/en/latest/) SDN controller. An SDN application to specifically support virtual network isolation is currently under implementation.
**NOTE**: The current version of L2S-M utilizes a custom implementation of SDN controller. This sdn controller implementation can be seen at https://github.com/Networks-it-uc3m/l2sm-controller .
More information on how to deploy virtualise workloads attached to virtual networks can be seen in the [ping-pong](https://github.com/Networks-it-uc3m/L2S-M/tree/main/examples/ping-pong) example.
More information on how to use this solution can be seen in the [how to use guide](./general-use.md).
This document will guide you through the usage of L2S-M, a tool designed to manage L2 networks, overlays, and Network Edge Devices (NEDs) within a Kubernetes cluster environment. L2S-M uses Custom Resource Definitions (CRDs) to enable flexible network management and pod attachment within Kubernetes.
For more specific examples, you can go to the [examples section](../examples/), this document is meant to be a general use guide.
## Custom Resource Definitions (CRDs)
L2S-M introduces three core CRDs that allow users to configure networks, overlays, and edge devices dynamically:
### 1. **L2Network CRD**
-**Purpose**: Defines a Layer 2 virtual network inside the Kubernetes environment.
-**Configurable Fields**:
-**Network Type**: Specifies the type of network.
-**Connectivity**: Controls the connection with the Software-Defined Networking (SDN) controller.
-**Connected Pods**: Lists the pods connected to this network.
-**Usage**: Once a network is defined, pods can be connected to it. The L2Network CRD provides specifications through the `spec` field, where the user defines the network attributes, while the `status` field reports the current state of the network, including the pods connected to it.
- An example of this CR can be found [here](../config/samples/l2sm_v1_l2network.yaml)
### 2. **Overlay CRD**
-**Purpose**: Defines the logical connections between nodes in the cluster, creating the overlay network.
-**Configurable Fields**:
-**Topology**: Specifies how nodes should be interconnected.
-**Switch Template**: Defines the type of switches used within the overlay.
-**Network Controller**: Identifies the SDN controller responsible for managing the topology.
-**Usage**: Administrators can use the Overlay CRD to define the connections between nodes based on their resource capacities or geographic location, creating custom topologies suited to specific needs.
- An example of this CR can be found [here](../config/samples/l2sm_v1_overlay.yaml)
### 3. **NetworkEdgeDevice (NED) CRD**
-**Purpose**: Extends the network beyond the cluster, enabling communication with external networks or other clusters.
-**Configurable Fields**:
-**Device Type**: Defines the hardware or software that forms the edge device.
-**Connections**: Specifies the external networks or clusters this NED should connect to.
-**Usage**: The NED CRD facilitates inter-cluster communication by connecting Kubernetes clusters or other platforms like OpenStack. Each NED is controlled by an SDN controller for dynamic flow control and traffic management.
- An example of this CR can be found [here](../config/samples/l2sm_v1_networkedgedevice.yaml)
## Attaching Pods to Networks
Pods can be dynamically attached to L2 networks defined by the L2Network CRD. This process involves the following steps:
1.**Defining the L2Network**: Use the L2Network CRD to create a network in Kubernetes. The network will be managed by the L2S-M controller, which communicates with the SDN controller to configure the necessary networking parameters.
2.**Scheduling Pods**: When a pod is deployed in the cluster, it can be attached to the L2Network by specifying the network during the pod creation process. The L2S-M controller will automatically configure the required network interfaces and assign IP addresses via the integrated IP Address Management (IPAM) system.
3.**Monitoring Connectivity**: Once attached, the status of the pod’s network connectivity can be checked via the L2Network CRD’s `status` field, which will list all connected pods and report any changes in the connectivity state.
