# A Novel Framework for Cross-Cluster Scaling in Cloud-Native 5G NextGen Core
## 3 Comparison between ETSI MANO and Kubernetes  
The traditional ETSI MANO framework relies on virtualization at its core. In Kubernetes, the applications are containerized on top of virtualization and referred to as containerized network functions (CNFs). Nevertheless, an accurate mapping between ETSI requirements and Kubernetes can be established. The ETSI IFA029 [60] specification translates VIM and VNFM architecture into a container framework by creating new concepts such as Container Infrastructure Service (CIS), Container Infrastructure Service Management (CISM), and Container Infrastructure Service Instance (CISI).  
MANO framework has three main components: NFV Orchestrator (NFO), VNF Manager (VNF), and Virtualized Infrastructure Manager (VIM). The main characteristics of ETSI MANO lay in the use of lifecycle operating procedures between NFVO VNFM and VIM, which might cause duplicates or bottlenecks in the operating model, whereas the Kubernetes model promotes intent-driven operations on both southbound and northbound interfaces using manifests and APIs. In our proposed architecture, the infrastructure layer is ensured through the cloud infrastructure, i.e., VMs on top of which Open5 GS is installed inside Kubernetes clusters. For the Open5 GS deployment, we employed the Kubernetes built-in object called ConfigMap, which allows a declarative configuration of the NFVs through APIs to specify the desired state of the operation.  
Therefore, it is essential to analyze all layers of the MANO architecture in order not to offload the details of the lower layers, i.e., virtual machines (VMs), to the upper layers (see Figure 1). In this regard, the ETSI MANO differs from the Kubernetes model since the VNFM (VNF Manager) holds a detailed view of deployed associated VNFs and exposes it northbound to NFVO. In Kubernetes, this information is not exported to the upper layers since Kubernetes offers a better way to control it by defining the intent through object definitions (such as labels, tags, selectors, taints, etc.). In Kubernetes, the concept of _pods_ exists to define where the containerized applications reside. Kubernetes manages the lifecycle of those pods by scaling up and down using changes in deployments and defining requirements in the configurations for the minimum, maximum, and desired number of replicas. In terms of operation, the NFVO can define the desired end state in a declarative manner using artifacts, such as deployment and service YAML files, and then the Kubernetes scheduler ensures the resource provisioning. Additionally, Kubernetes can use the automatic cluster scaler to request extra resources from an underlying cloud infrastructure to meet the additional needs of the Kubernetes workload [61].  
In the context of 5G SBA (Service-Based Architecture), network slicing involves the virtualization and replication of the entire service graph that implements the mobile core. A slice can be considered a system abstraction that keeps a record of the set of interconnected microservices running per slice and gives clear instructions to the underlying schedulers to allocate the required network bandwidth according to the service demands as well as the CPU scheduler to allocate enough cores to the running containers [62].