openair-k8s allows building high-quality OCI-compliant container images for the OpenAirInterface 4G/5G radio access (eNB/gNB) and core networks (EPC) and deploying these components on OpenShift or other enterprise-grade Kubernetes distributions.
Note: This is both experimental and work in progress.
OpenAirInterface (OAI) components have many build-time dependencies, some of which need to be built from source. To ensure fast yet reproducible image builds, we create a common oai-build-base
image that contains the build-time dependencies for all OAI components. Each component image is then built using the multistage build pattern: First build the OAI component using the oai-build-base
image, then copy the component and its run-time dependencies into a fresh deployment image.
Images are built based on RHEL8 Universal Base Images (UBI) to yield small images with curated, high-quality content.
As some of the required rpm packages for building OAI are not yet available via the UBI repos, images currently need to be built on a subscribed RHEL8 host, e.g. using the free RHEL8 developer subscriptions. On the RHEL8 build host:
sudo subscription-manager register
sudo subscription-manager attach
sudo yum install -y git podman nmap-ncat
git clone http://github.com/OPENAIRINTERFACE/openair-k8s
cd openair-k8s
To build all OAI component images:
hack/build_images
To build selected OAI component images, e.g.:
hack/build_images oai-enb oai-ue
By default, OAI components are built using the stable git tag defined in the component's Dockerfile. To override this, specify an alternative git ref to build from, e.g.:
hack/build_images oai-enb:v1.0.0 oai-ue:master
To push the OAI images to an external registry, e.g. oai-hss to quay.io:
podman login quay.io
podman push oai-hss:1.0.1 quay.io/my_organisation/oai-hss:1.0.1
To delete all local OAI component images:
hack/clean_images
Add --help
to these commands to see more options.
To run a linter on all Dockerfiles:
hack/check_dockerfiles
OAI containers will run with host networking (--net=host
) and communicate via the loopback 127.0.1.1
. To ensure the services' names can be properly resolved, add the following to /etc/hosts
:
127.0.1.1 hss hss.openair4G.eur
127.0.1.1 mme mme.openair4G.eur
127.0.1.1 sgw sgw.openair4G.eur
To test the OAI container images on your local machine, you can run them in podman like this:
hack/run_oai_on_podman
To delete the container instances created with above command, use:
hack/clean_oai_on_podman
Obviously, a running k8s cluster with kubectl
set up correctly. This work is being developed and tested on OpenShift 4.2 (try it here). You also need kustomize
installed:
curl -L https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64 -o ~/bin/kustomize && chmod a+x ~/bin/kustomize
If necessary, generate new TLS certificates for the oai-hss and oai-mme services to match the namespace and cluster name you're deploying to, e.g.:
hack/generate_certs -p hss -d manifests/oai-hss/certs oai-hss.oai.svc.cluster.local
hack/generate_certs -p mme -d manifests/oai-mme/certs oai-mme.oai.svc.cluster.local
If your user has permissions to create namespaces on the k8s cluster, you can simply run:
hack/run_oai_on_k8s
... which internally calls:
kustomize build manifests | kubectl apply -f -
If you need to use a namespace assigned to you, e.g. oai
, modify manifests/kustomization.yaml
to delete the 00_namespace.yaml
resource and change the namespace
field to your needs.
In order to run a single component, you have to point to the specific path where the manifests are located. For instnace, to run the MME on Kubernetes/OpenShift, please run:
kustomize build manifests/oai-mme | kubectl apply -f -
and to delete that component from running on the cluster, execute:
kustomize build manifests/oai-mme | kubectl delete -f -
To remove all resources from the 'oai' namespace plus delete the namespace itself, run:
hack/clean_oai_on_k8s