- Directory spiw-lab3: Lab3 guide for the SPIW course (pdf document)
- Directory open5gs: instructions and Helm charts to install and run 5g network in a RPi cluster
- Directory looptest: examples of reading Open5GS monitoring information from Prometheus
- File
install_helm.sh: script to install HELM
If Helm is not installed on your host, install it running the script install_helm.sh from this repo. We will use Helm for deploying 5G RAN and core network parts, and also to activate/deactivate user equipment (UE) for scaling purposes.
Detailed description is contained in directory open5gs. Here, we assume that you have your k3s on Raspberry Pi 4 or 5 cluster up an running, including the monitoring package based on kube-prometheus project (full installation of our k3s cluster is described here). Installing 5G network environment is done in two steps. In the first step you will install 5G core network (Open5GS platform). In the second step you will install UERANSIM - RAN network emulator. Installation is straightforward - both parts are installed using Helm. Initial configuration of UERANSIM deploys with 4 user equipments (UE, correspond to mobile terminals) attached to the network and active (in the 5G mobile network sense). Helm will also be used to attach new/detach existing UEs to/from the network. The content open5gs of open5gs covers only the installation of the 5G environment and basic operation of UERANSIM RAN emulator to activate and deactivate user equipment. For detailed instructions, please refer to the README file in the open5gs directory.
Having installed 5G network, you can start monitoring and managing 5G core network according to guidelines provided in directory looptest.
Important
To get ready, read the README file in the the looptest directory. If previously you followed all our installation guides then in place pod vertical scaling should be enabled already. If not it can be enabled now which is described here.
Our goal is to illustrate how a service-level metric can be monitored in Open5GS core network and used in a simple control loop to scale selected network function (more specifically, a container performing the function of UPF in 5G core network). The lab focuses on the monitoring aspect and demonstrating a simple implementation of the scaling operation. The control loop will combine monitoring and scaling. You will design it within the project that follows the lab. However, we do not use Kubernetes operator framework for that. Instead, we use an external application containing all loop logic. We expect the lab and project will provide you with a foundation for designing and implementing your own, even more advanced control loops in Kubernetes.
Note
Using Kubernetes Operator Framework is a native approach to orchestrate resources in Kubernetes. However, the entry level to this framework is quit high and so beyond the scope of our course. Additionally, Kubernetes operators may not be the best choice for managing higher-level abstractions with a complex logic. In such cases, it may be more appropriate to use dedicated applications having access to Kubernetes API, and our solution here follows this approach.
The control loop, driven by a selected service-level metric, will actuate on the resource level. It will vertically scale the UPF container in 5G core network (so without recreating the pod). Vertical scaling (in-place scaling) is beneficial for statefull services (while horizontal scaling may not suitable for stateful services). In Kubernetes, it is known as the so called In Place Pod Vertical Scaling (or In-Place Pod Resize). This feature was relatively new in Kubernetes (alpha status) during the preparation of the main part of this guide. It graduated to stable only in the release 1.35. We are currently using K3s v1.34 and apply relevant K3s installation procedure where InPlacePodVerticalScaling feature gate has to be explicitly enabled either during the installation or in a running cluster. Since Kubernetes 1.35, this feature gate has been enabled by default and should work out of the box (there's no need for manual configurations). One can give it a try together with the latest kube-prometheus release, but we have not checked those newer configurations so far in our environment.