Katana Slice Manager
📃 Introduction to Network Slicing
Network slicing is a 5G cutting edge technology that enables the creation of multiple virtual networks on top of shared physical infrastructure, allowing operators to provide portions of their networks that fit the requirements defined by various vertical industries. A network slice can be described as the collection of multiple sub-slices of different domains, such as the Core Datacenter, the Transport network, and one or numerous Edge Locations. The figure below depicts some examples of 5G Network Slices:
Katana Slice Manager is a centralized software component that provides an interface for creating, modifying, monitoring, and deleting slices. Through the North Bound Interface (NBI), the Slice Manager receives the Network Slice Template (NEST) for creating network slices and provides the API for managing and monitoring them. Through the South Bound Interface (SBI), it communicates with the Network Sub-Slice Manager components of the Management Layer, namely the Virtual Infrastructure Manager (VIM), the NFV Orchestrator (NFVO), the Element Management System (EMS), and the WAN Infrastructure Management (WIM).
Katana Slice Manager is based on a highly modular architecture, built as a mesh of microservices, each of which is running on a docker container. The key advantages of this architectural approach are that it offers simplicity in building and maintaining applications, flexibility and scalability, while the containerized approach makes the applications independent of the underlying system.
📋 Features
- Start, Stop, Inspect End-to-End Network Slices
- OpenAPIs supported by Swagger-io tool
- Modular architecture for supporting different infrastructure technologies
- Integrated CLI tool
- Slice Day-2 operations
- Prometheus and Grafana Monitoring modules
- Integrated Policy Engine System
- Slice Deployment and Configuration measurements
- CI/CD procedures
⚒️ Quick Start
Requirements
- docker version >= 18.09.6
- docker-compose version >= 1.17.1
Build
Build the Katana Docker images and install the katana CLI command on the local system.
bash bin/build.sh [-r | --release <RELEASE_NUMBER>] [--docker_reg <REMOTE_DOCKER_REGISTRY>] [--docker_repo <DOCKER_REPOSITORY>] [--docker_reg_user <REGISTRY_USER>] [--docker_reg_passwd <REGISTRY_PASSWORD>] [--push] [--dev] [-h | --help]Options:
- [-r | --release <RELEASE_NUMBER>] : Define the release that will match the Docker Tag of Katana Docker images (Default: :test).
- [--docker_reg <REMOTE_DOCKER_REGISTRY>] : Define the remote Docker registry. If no docker registry is specified, Katana will try to use the public Docker hub
- [--docker_repo <DOCKER_REPOSITORY>] : Define the Docker repository
- [--docker_reg_user <REGISTRY_USER>] : Define the user of the remote Docker registry
- [--docker_reg_passwd <REGISTRY_PASSWORD>] : Define the password for the user of the remote Docker registry
- [--push] : Push the images to the remote Docker registry
- [--dev] : Create a dev workspace for development purposes
- [-h | --help] : Print this message and quit
Sudo privileges will be needed for installing the CLI command tool
Deploy
Deploy katana Slice Manager service. The script will attempt to pull the defined Docker tag from the defined Docker registry/repository. Otherwise, it will build the images using the ":test" tag.
bash bin/deploy.sh [-p | --publish] [-r | --release <RELEASE_NUMBER>] [--docker_reg <REMOTE_DOCKER_REGISTRY>] [--docker_repo <DOCKER_REPOSITORY>] [--docker_reg_user <REGISTRY_USER>] [--docker_reg_passwd <REGISTRY_PASSWORD>] [-m | --monitoring] [--no-build] [--apex] [-h | --help]Options:
- [-p | --publish] : Expose Kafka end Swagger-ui using katana public IP
- [-r | --release <RELEASE_NUMBER>] : Define the release that will match the Docker Tag of Katana Docker images (Default: :test).
- [--docker_reg <REMOTE_DOCKER_REGISTRY>] : Define the remote Docker registry. If no docker registry is specified, Katana will try to use the public Docker hub
- [--docker_repo <DOCKER_REPOSITORY>] : Define the Docker repository
- [--docker_reg_user <REGISTRY_USER>] : Define the user of the remote Docker registry
- [--docker_reg_passwd <REGISTRY_PASSWORD>] : Define the password for the user of the remote Docker registry
- [-m | --monitoring] : Start Katana Slice Manager Slice Monitoring module
- [--no_build] : Try to download Docker images, but do not build them
- [--apex] : Initiate the APEX Policy Engine
- [-h | --help] : Print help message and quit
Logs
Get the logs of katana-mngr and katana-nbi modules:
katana logs [-l | --limit N]- -l | --limit: Show a limited number of lines from the end of the logs (default "all")
Stop
Stop Katana Slice Manager:
bash bin/stop.sh [-c | --clear] [-h | --help]- [-c | --clear] : Remove the container volumes
- [-h | --help] : Print help message and quit
Uninstall
Remove katana Docker resources and the CLI command tool
bash bin/uninstall.shSudo privileges will be needed for removing the CLI command tool
Monitoring
To start Prometheus and Grafana Monitoring modules add the -m | --monitoring flag to deploy.sh binary. Prometheus is running at port 9090 and Grafana at port 3000. A new dashboard will be created on Grafana for every new slice that is created.
By default Grafana credentials are admin:admin. To change it, create the katana-grafana/.env file with the following environmental variables:
GF_SECURITY_ADMIN_USER=USER
GF_SECURITY_ADMIN_PASSWORD=PASSWORD⌨️ Development Environment
To create a development environment for katana on a Linux host, run:
bash bin/build.sh --devThis will create hard links of the shared_utils directory of both katana-mngr and katana-nbi on the root directory ./dev_shared_utils. So any changes done on the existing files ./shared_utils directory will be reflected to katana-mngr/katana/shared_utils and katana-nbi/katana/shared_utils directories. To add new files that are created in the dev_shared_utils directory, run the command:
for dest in katana-{mngr,nbi}/katana/shared_utils/; do cp -al dev_shared_utils/{PATH_TO_NEW_FILE} $dest; doneIt will also create a dev folder, where the example_config_files will be copied for providing direct access to testing configuration files.
You can also check the Wiki "For Developers" page for more details.
✔️ CI/CD
The current implementation supports two pipelines, using the respective Jenkinsfile:
Development/Integration Pipeline
- CI Pipeline using the file jenkins/ci/Jenkinsfile:
- Builds the Katana Docker images and deploys a testing instance of Katana SM
- Runs the defined Functional and Integration tests. Tests are defined in the folder jenkins/ci/tests
- If the changes are occurring on the master branch, the built images will be packaged and uploaded to the defined Docker registry
- Required parameters/variables on Jenkins:
- katana_reg: The remote Docker registry that will be used for pushing Docker Images
- katana_repo: The remote Docker repository that will be used for pushing Docker Images
- test_server: The label of the Jenkins agent that will be used for running the testing Katana instance
- Required credentials on Jenkins:
- katana-reg-creds: Username/Password for the remote Docker registry
This Pipeline is executed on a testing environment
Deployment Pipeline
- CD Pipeline using the file jenkins/cd/Jenkinsfile:
- Builds the docker images using the latest tag
- Deploys the latest version of Katana SM on the defined Operational environment
- Sends notification on Slack
- Required parameters/variables on Jenkins:
- katana_reg: The remote Docker registry that will be used for pushing Docker Images
- katana_repo: The remote Docker repository that will be used for pushing Docker Images
- prod_server: The label of the Jenkins agent that will be used for running the stable Katana instance
- prod_server_ip: The IP Address of the production server that will be used for hosting the stable Katana instance
- Required credentials on Jenkins:
- katana-reg-creds: Username/Password for the remote Docker registry
This Pipeline is executed on a stable production/staging environment