1. Network Repository Function (NRF) Cloud Native Installation and Upgrade Guide
  2. Installing OCNRF

2 Installing OCNRF

This section describes the prerequisites and installation procedure for OCNRF.

Prerequisites

This section includes information about the required prerequisites before initiating OCNRF Installation.

Following are the prerequisites to install and configure OCNRF:

OCNRF Software

The OCNRF software includes:

  • OCNRF Helm charts
  • OCNRF docker images

The following softwares must be installed before installing OCNRF:

Software Version
Kubernetes v1.15.3
HELM v2.14.3

Additional software that needs to be deployed as per the requirement of the services:

Software Chart Version Notes
elasticsearch 5.5.4 Needed for Logging Area
elastic-curator 5.5.4 Needed for Logging Area
elastic-exporter 1.0.2 Needed for Logging Area
logs 2.0.7 Needed for Logging Area
kibana 6.7.0 Needed for Logging Area
grafana 6.1.6 Needed for Metrics Area
prometheus 9.1.2 Needed for Metrics Area
prometheus-node-exporter 0.17.0 Needed for Metrics Area
metallb 0.7.3 Needed for External IP
metrics-server 0.3.1 Needed for Metric Server
tracer 0.8.3 Needed for Tracing Area

Note:

Install the specified software items before proceeding, if any of the above services are needed and the respective software is not already installed in CNE.
To check the installed software items, execute: 
helm ls

Some of the systems may need to use helm command with admin.conf file, such as:

helm --kubeconfig admin.conf

Network access

The Kubernetes cluster hosts must have network access to:

  • Local docker image repository where the OCNRF images are available.
    To check if the Kubernetes cluster hosts has network access to the local docker image repository, try to pull any image with tag name to check connectivity by executing: 
    docker pull <docker-repo>/<image-name>:<image-tag>

    Note:

    Some of the systems may need to use helm command with admin.conf file, such as:

    helm --kubeconfig admin.conf

  • Local helm repository where the OCNRF helm charts are available.
    To check if the Kubernetes cluster hosts has network access to the local helm repository, execute: 
    helm repo update

    Note:

    Some of the systems may need to use helm command with admin.conf file, such as:

    helm --kubeconfig admin.conf

Note:

All the kubectl and helm related commands that are used in this document must be executed on a system depending on the infrastructure of the deployment. It could be a client machine such as a VM, server, local desktop, and so on.

Client machine requirement

Client machine needs to have the following minimum requirements:
  • It should have network access to the helm repository and docker image repository.
  • Helm repository must be configured on the client.
  • It should have network access to the Kubernetes cluster.
  • It should have necessary environment settings to run the kubectl commands. The environment should have privileges to create a namespace in the Kubernetes cluster.
  • It should have helm client installed. The environment should be configured so that the helm install command deploys the software in the Kubernetes cluster.

Server or Space Requirements

For information on the server or space requirements, see the Oracle Communications Cloud Native Environment (OCCNE) Installation Guide.

Secret file requirement

For HTTPs and Access token, the following certs and pem files has to be created before creating secret files for Keys and MySql.

Note: The following files must be created before creating secret files.
  1. ECDSA private Key and CA signed ECDSA Certificate (if initialAlgorithm: ES256)
  2. RSA private key and CA signed RSA Certificate (if initialAlgorithm: RSA256)
  3. TrustStore password file
  4. KeyStore password file
  5. CA signed ECDSA certificate

ServiceAccount requirement

Operator must create a service account, bind it with a Role for resource with permissions for atleast get, watch and list.

serviceAccountName is a mandatory parameter. Kubernetes Secret resource is used for providing the following:

  • MYSQL DB Details to micro-services.

  • NRF's Private Key, NRF's Certificate and CA Certificate Details to Ingress/Egress Gateway for TLS.

  • NRF's Private and NRF's Public Keys to nfAccessToken micro-service for Digitally Signing AccessTokenClaims.

  • Producer/Consumer NF's Service/Endpoint details for routing messages from/to Egress/Ingress Gateway.

The Secret(s) can be under same namespace where OCNRF is getting deployed (recommended) or # Operator can choose to use different namespaces for different secret(s). If all the Secret(s) are under same namespace as OCNRF, then Kubernetes Role can be binded with the given ServiceAccount. Otherwise ClusterRole needs to be binded with the given ServiceAccount. The Role/ClusterRole needs to be created with resources: (services, configmaps, pods, secrets, endpoints) and (verbs: get, watch, list). Refer to Creating Service Account, Role and Role bindings for more details.

Installation Sequence

This section explains the tasks to be performed for installing OCNRF.

OCNRF pre-deployment configuration

This chapter divided into different sections:

  1. Creating OCNRF namespace

    Note:

    This is a mandatory procedure, execute this before proceeding any further. The namespace created/verified in this procedure is an input for next procedures.
  2. Creating Service Account, Role and Role bindings

    Note:

    Following are sample steps, in case of already configured service account with role and role-bindings or the user has previously prepared procedure to create service account, skip this procedure.
  3. Configuring MySql database and user
  4. Configuring MySQL secret
  5. Configuring secrets for enabling HTTPS
  6. Configuring secret for enabling AccessToken service
Creating OCNRF namespace

This section explains how the user can verify if the required namespace is available in the system or not. If namespace does not exists, the user must create it.

Procedure

  1. Verify required namespace already exists in system: 
    $ kubectl get namespaces
  2. In the output of the above command, check if required namespace is available. If not available, create the namespace using following command:

    Note:

    This is an optional step. In case required namespace already exists, proceed with next procedures. 
    $ kubectl create namespace <required namespace>
    For example:- 
    $ kubectl create namespace ocnrf
Creating Service Account, Role and Role bindings

This section explains how user can create service account, required role and role bindings resources. Sample templates for the resources is as follows. Sample template can be filled inline and can be added into sample resource input yaml file. Input file name example:- ocnrf-sample-resource-template.yaml

Example command for creating the resources 

kubectl -n <ocnrf-namespace> create -f ocnrf-sample-resource-template.yaml

Sample template to create the resources

Note:

Update <helm-release> and <namespace> with respective ocnrf namespace and planned ocnrf helm release name in below place holders. 
## Sample template start#
apiVersion: v1
kind: ServiceAccount
metadata:
  name: <helm-release>-ocnrf-serviceaccount
  namespace: <namespace>
---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: <helm-release>-ocnrf-role
  namespace: <namespace>
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  verbs:
  - get
  - watch
  - list
---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: <helm-release>-ocnrf-rolebinding
  namespace: <namespace>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: <helm-release>-ocnrf-role
subjects:
- kind: ServiceAccount                                   
  name:  <helm-release>-ocnrf-serviceaccount
  namespace: <namespace>
## Sample template end#
Configuring MySql database and user

Procedure for Geo-Redundant OCNRF sites

This section explains how database administrator can create the OCNRF database and OCNRF application user.

Note:

  1. Procedure can be different for geo-redundant OCNRF sites and standalone OCNRF site.
  2. For geo-redundant sites, before executing below procedure, assumption is geo-redundant DB-Tier sites are already up and replication channels enabled.
  1. Login to the machine which has permission to access the SQL nodes of NDB cluster.
  2. Connect to the SQL node of NDB cluster successively. MySQL commands must be executed on all the SQL nodes.
  3. Login to the MySQL prompt using root permission or user, which has permission to create users with conditions as mentioned below. For example: mysql -h 127.0.0.1 -uroot -p

    Note:

    This command may vary from system to system, path for mysql binary, root user and root password. After executing this command, user need to enter the password specific to the user mentioned in the command.
  4. Check OCNRF network function user already exists. If the user does not exists, create an OCNRF network function user by executing the following command: 
    # Check if user exists or not
$ SELECT User FROM mysql.user;
 
# In case, user already exists, move to next step.
# Command to create new user:-
$ CREATE USER '<OCNRF User Name>'@'%' IDENTIFIED BY '<OCNRF Password>';
 
# Example:-
$ CREATE USER 'nrfusr'@'%' IDENTIFIED BY 'nrfpasswd'
  5. Check OCNRF network function database already exists. If the database does not exists, create an OCNRF network function database and provide permissions to OCNRF user name created in above step:
    Execute the following command to check if database exists:- 
    $ show databases;

    In case database already exists, then move to next step. Else, create database using the following command: 

    $ CREATE DATABASE IF NOT EXISTS <OCNRF Database> CHARACTER SET utf8;
    Example:- 
    $ CREATE DATABASE IF NOT EXISTS nrfdb CHARACTER SET utf8;
    Granting permission to user:- 
     $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON
<OCNRF Database>.* TO '<OCNRF User Name>'@'%';
    Example:- 
    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON
nrfdb.* TO 'nrfusr'@'%';
  6. Exit from MySQL prompt and SQL nodes.

Note:

Execute the commands on each SQL node on only one geo-redundant site. Other geo-redundant site(s) will get the data replicated automatically.

Procedure for standalone OCNRF site

  1. Login to the machine which has permission to access the SQL nodes of NDB cluster.
  2. Connect to the SQL node of NDB cluster successively. MySQL commands must be executed on all the SQL nodes.
  3. Login to the MySQL prompt using root permission or user, which has permission to create users with conditions as mentioned below. For example: mysql -h 127.0.0.1 -uroot -p

    Note:

    This command may vary from system to system, path for mysql binary, root user and root password. After executing this command, user need to enter the password specific to the user mentioned in the command.
  4. Check OCNRF network function user already exists. If the NF does not exists, create an OCNRF network function user by executing the following command: 
    $ SELECT User FROM mysql.user;
    In case the user already exists, move to next step. Else, Execute the following command to create new user:
     $ CREATE USER '<OCNRF User Name>'@'%' IDENTIFIED BY '<OCNRF Password>';
    Example:- 
    $ CREATE USER 'nrfusr'@'%' IDENTIFIED BY 'nrfpasswd';
  5. Check OCNRF network function database already exists. If the database does not exists, create an OCNRF network function database and provide permissions to OCNRF user name created in above step:
    Execute the following command to check if database exists:- 
    $ show databases;
    Check if required database is already in list. In case the database already exists, then move to next step. Else, create the database using the following command:
     $ CREATE DATABASE IF NOT EXISTS <OCNRF Database> CHARACTER SET utf8;
    Example:- 
    $ CREATE DATABASE IF NOT EXISTS nrfdb CHARACTER SET utf8;
    Granting permission to user:- 
    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP,LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON
<OCNRF Database>.* TO '<OCNRF User Name>'@'%';
    Example:- 
    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON
nrfdb.* TO 'nrfusr'@'%';
  6. Exit from MySQL prompt and SQL nodes.

Note:

Execute the commands on each SQL node of standalone site.
Configuring MySQL secret

MySQL secret creation

This section explains the steps for accessing MySql database and user details created by database administer in above section. This section must be execute before deploying OCNRF.

Following is the procedure to create and verify the secret:
  1. Execute the following command to create kubernetes secret:
    $ kubectl create secret generic <database secret name> --from-literal=dbUsername=<OCNRF Mysql database username> --from-literal=dbPassword=<OCNRF Mysql database passsword> --from-literal=dbName=<OCNRF Mysql database name> -n <Namespace of MYSQL secret>

    Note:

    Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.

    Example 

    $ kubectl create secret generic database-secret --from-literal=dbUsername=nrfusr --from-literal=dbPassword=nrfpasswd --from-literal=dbName=nrfdb -n ocnrf
  2. Execute the following command to verify the secret creation:
     $ kubectl describe secret <database secret name> -n <Namespace of MYSQL secret>

    Example 

     $ kubectl describe secret database-secret -n ocnrf

MySQL secret update

This section explains how to update the mysql secret with updated details.
  1. Copy the exact command used in above section during creation of secret:
    $ kubectl create secret generic <database secret name> --from-literal=dbUsername=<OCNRF Mysql database username> --from-literal=dbPassword=<OCNRF Mysql database passsword> --from-literal=dbName=<OCNRF Mysql database name> -n <Namespace of MYSQL secret>
  2. Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MYSQL secret>".
  3. Create secret command will look like:
    $ kubectl create secret generic <database secret name> --from-literal=dbUsername=<OCNRF Mysql database username> --from-literal=dbPassword=<OCNRF Mysql database passsword> --from-literal=dbName=<OCNRF Mysql database name> --dry-run -o yaml -n <Namespace of MYSQL secret> | kubectl replace -f - -n <Namespace of MYSQL secret>
  4. Execute the updated command.
  5. After successful secret update, the following message is displayed:
    secret/<database secret name> replaced
Configuring secrets for enabling HTTPS

Creation of secrets for enabling HTTPS in OCNRF Ingress gateway

This section explains the steps to create secret for HTTPS related details. This section must be executed before enabling HTTPS in OCNRF Ingress gateway.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files below.
To create kubernetes secret for HTTPS, following files are required:-
  • ECDSA private key and CA signed certificate of OCNRF (if initialAlgorithm is ES256)
  • RSA private key and CA signed certificate of OCNRF (if initialAlgorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.

  1. Execute the following command to create secret: 
    $ kubectl create secret generic <ocingress-secret-name> --fromfile=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of OCNRF Ingress Gateway secret>

    Note:

    Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.
    Example: The names used below are same as provided in custom values.yaml in OCNRF deployment. 
    $ kubectl create secret generic ocingress-secret --fromfile=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n ocnrf
  2. Verify the secret created using the following command:
    $ kubectl describe secret <ocingress-secret-name> -n <Namespace of OCNRF Ingress Gateway secret>
    Example: 
    $ kubectl describe secret ocingress-secret -n ocnrf

Update the secrets for enabling HTTPS in OCNRF Ingress gateway

This section explains how to update the secret with updated details.

  1. Copy the exact command used in above section during creation of secret.
  2. Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of OCNRF Ingress Gateway secret>".
  3. Create secret command will look like:
    $ kubectl create secret generic <ocingress-secret-name> --fromfile=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of OCNRF Ingress Gateway secret> | kubectl replace -f - -n <Namespace of OCNRF Ingress Gateway secret>

    Example:-

    The names used below are same as provided in custom_values.yaml in OCNRF deployment:
    $ kubectl create secret generic ocingress-secret --fromfile=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf
  4. Execute the updated command.
  5. After successful secret update, the following message is displayed:
    secret/<ocingress-secret> replaced

Creation of secrets for enabling HTTPS in OCNRF Egress gateway

This section explains the steps to create secret for HTTPS related details. This section must be executed before enabling HTTPS in OCNRF Egress gateway.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files below.

To create kubernetes secret for HTTPS, following files are required:-

  • ECDSA private key and CA signed certificate of OCNRF (if initialAlgorithm is ES256)
  • RSA private key and CA signed certificate of OCNRF (if initialAlgorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.
  1. Execute the following command to create secret. 
    $ kubectl create secret generic <ocegress-secret-name> --fromfile=<ssl_ecdsa_private_key.pem>  --from-file=<ssl_rsa_private_key.pem> --fromfile=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<ssl_cabundle.crt> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of OCNRF Egress Gateway secret>

    Note:

    Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.

    Example: The names used below are same as provided in custom_values.yaml in OCNRF deployment.

    $ kubectl create secret generic ocegress-secret --fromfile=ssl_ecdsa_private_key.pem --from-file=ssl_rsa_private_key.pem --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=ssl_cabundle.crt --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n ocnrf
  2. Command to verify secret created: 
    $ kubectl describe secret <ocegress-secret-name> -n <Namespace of OCNRF Egress Gateway secret>

    Example:

    $ kubectl describe secret ocegress-secret -n ocnrf

Update the secrets for enabling HTTPS in OCNRF Egress gateway

This section explains how to update the secret with updated details.

  1. Copy the exact command used in above section during creation of secret:
  2. Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of OCNRF Egress Gateway secret>".
  3. Create secret command will look like:
    kubectl create secret generic <ocegress-secret-name> --fromfile=<ssl_ecdsa_private_key.pem> --from-file=<ssl_rsa_private_key.pem> --fromfile=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<ssl_cabundle.crt> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of OCNRF Egress Gateway secret> | kubectl replace -f - -n <Namespace of OCNRF Egress Gateway secret>

    Example:-

    The names used below are same as provided in custom_values.yaml in OCNRF deployment:
    $ kubectl create secret generic egress-secret --fromfile=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf
  4. Execute the updated command.
  5. After successful secret update, the following message is displayed:
    secret/<ocegress-secret> replaced
Configuring secret for enabling AccessToken service

Access Token secret creation

This section explains the steps to create secret for AccessToken service of OCNRF. This section must be executed before enabling Access Token in OCNRF.

Note:

The passwords for KeyStore is stored in respective password file below.

To create kubernetes secret for HTTPS, following files are required:-

  • ECDSA private key and CA signed certificate of OCNRF (if initialAlgorithm is ES256)
  • RSA private key and CA signed certificate of OCNRF (if initialAlgorithm is RSA256)
  • KeyStore password file

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.
  1. Execute the following command to create secret. The names used below are same as provided in custom values.yaml in OCNRF deployment: 
    $ kubectl create secret generic <ocnrfaccesstoken-secret-name> --fromfile=<ecdsa_private_key.pem> --from-file=<rsa_private_key.pem> --fromfile=<ssl_truststore.txt> --from-file=<keystore_password.txt> --fromfile=rsa_certificate.crt --from-file=<ecdsa_certificate.crt> -n <Namespace of OCNRF AccessToken secret>

    Note:

    Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.
    Example:
    $ kubectl create secret generic ocnrfaccesstoken-secret --fromfile=ecdsa_private_key.pem --from-file=rsa_private_key.pem --fromfile=ssl_truststore.txt --from-file=keystore_password.txt --fromfile=rsa_certificate.crt --from-file=ecdsa_certificate.crt -n ocnrf
  2. Execute the following command to verify secret created: 
    $ kubectl describe secret <ocnrfaccesstoken-secret-name> -n <Namespace of OCNRF AccessToken secret>

    Example:

     $ kubectl describe secret ocnrfaccesstoken-secret -n ocnrf

Access Token secret update

This section explains how to update the access token secret with updated details.
  1. Copy the exact command used in above section during creation of secret.
  2. Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of Access Token secret>".
  3. Create secret command will look like:
    kubectl create secret generic <ocnrfaccesstoken-secret> --fromfile=<ecdsa_private_key.pem> --from-file=<rsa_private_key.pem> --fromfile=<ssl_truststore.txt> --from-file=<keystore_password.txt> --fromfile=<rsa_certificate.crt> --from-file=<ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of Access Token secret> | kubectl replace -f - -n <Namespace of Access Token secret>

    Example:-

    The names used below are same as provided in custom_values.yaml in OCNRF deployment:
    $ kubectl create secret generic ocnrfaccesstoken-secret --fromfile=ecdsa_private_key.pem --from-file=rsa_private_key.pem --fromfile=ssl_truststore.txt --from-file=keystore_password.txt --fromfile=rsa_certificate.crt --from-file=ecdsa_certificate.crt --dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf
  4. Execute the updated command.
  5. After successful secret update, the following message is displayed:
    secret/<ocnrfaccesstoken-secret> replaced

Installation Tasks

This section describes the tasks that the user needs to follow for installing OCNRF.

Downloading OCNRF package

Following is the porcedure to download the release package from MOS:
  1. Login to MOS using the appropriate login credentials.
  2. Select Product & Updates tab.
  3. In Patch Search console select Product or Family (Advanced) tab.
  4. Enter Oracle Communications Cloud Native Core - 5G in Product field and select the product from the Product drop-down.
  5. Select Oracle Communications Cloud Native Core Network Repository Function <release_number> in Release field.
  6. Click Search. The Patch Advanced Search Results list appears.
  7. Select the required patch from the list. The Patch Details window appears.
  8. Click on Download. File Download window appears.
  9. Click on the <p********_<release_number>_Tekelec>.zip file.
  10. Click on the zip file to download the network function patch to the system where network function must be installed.

Install OCNRF

  1. Unzip the release package file to the system where you want to install the network function. You can find the OCNRF package as follows:

    ReleaseName-pkg-Releasenumber.tgz

    where:

    ReleaseName is a name which is used to track this installation instance.

    Releasenumber is the release number.

    For example, ocnrf-pkg-1.6.1.0.0.tgz
  2. Untar the OCNRF package file to get OCNRF docker image tar file:
    tar -xvzf ReleaseName-pkg-Releasenumber.tgz
  3. Load the ocnrf-images-<release_number>.tar file into the Docker system:
    docker load --input /IMAGE_PATH/ocnrf-images-<release_number>.tar
  4. Verify that the image is loaded correctly by entering this command:
    docker images
  5. Execute the following commands to push the docker images to docker registry: 
    docker tag <image-name>:<image-tag> <docker-repo>/ <image-name>:<image-tag>
    docker push <docker-repo>/<image-name>:<image-tag>
  6. Untar the helm files: 
    tar -xvzf ocnrf-<release_number>.tgz
  7. Create the customize ocnrf-custom-values-1.6.1.yaml file with the required input parameters. To customize the file, refer to Customizing OCNRF chapter.
  8. Go to the extracted OCNRF package as explained in:
    cd ocnrf-<release_number>
  9. Install OCNRF by executing the following command:
    helm install ocnrf/ --name <helm-release> --namespace <k8s namespace> -f <ocnrf_customized_values.yaml>

    Example: helm install ocnrf/ --name ocnrf --namespace ocnrf -f ocnrf-custom-values-1.6.1.yaml

  10. Execute the following command to check the status:

    helm status <helm-release>

    For example: helm status ocnrf

  11. Execute the following command to check status of the services:

    kubectl -n <k8s namespace> get services

    For example:

    kubectl -n ocnrf get services

    Note: If metallb is used, EXTERNAL-IP is assigned to <helm release name>-endpoint. ocnrf is the helm release name. 
    NAME                   TYPE          CLUSTER-IP     EXTERNAL-IP  PORT(S)            AGE
ocnrf-egressgateway    ClusterIP     10.233.1.61    <none>       8080/TCP,5701/TCP  30h
ocnrf-ingressgateway   LoadBalancer  10.233.52.194  <pending>    80:31776/TCP       30h
ocnrf-nfaccesstoken    ClusterIP     10.233.53.115  <none>       8080/TCP           30h
ocnrf-nfdiscovery      ClusterIP     10.233.21.28   <none>       8080/TCP           30h
ocnrf-nfregistration   ClusterIP     10.233.4.140   <none>       8080/TCP           30h
ocnrf-nfsubscription   ClusterIP     10.233.44.98   <none>       8080/TCP           30h
ocnrf-nrfauditor       ClusterIP     10.233.1.71    <none>       8080/TCP           30h
ocnrf-nrfconfiguration LoadBalancer  10.233.40.230  <pending>    8080:30076/TCP     30h
  12. Execute the following command to check status of the pods:

    kubectl get pods -n <k8s namespace>

    Status column of all the pods should be 'Running'.

    Ready column of all the pods should be n/n, where n is number of containers in the pod.

    For example:

    kubectl get pods -n ocnrf 
    NAME                                     READY  STATUS   RESTARTS  AGE
ocnrf-egressgateway-d6567bbdb-9jrsx      2/2    Running  0         30h
ocnrf-egressgateway-d6567bbdb-ntn2v      2/2    Running  0         30h
ocnrf-ingressgateway-754d645984-h9vzq    2/2    Running  0         30h
ocnrf-ingressgateway-754d645984-njz4w    2/2    Running  0         30h
ocnrf-nfaccesstoken-59fb96494c-k8w9p     2/2    Running  0         30h
ocnrf-nfaccesstoken-49fb96494c-k8w9q     2/2    Running  0         30h
ocnrf-nfdiscovery-84965d4fb9-rjxg2       1/1    Running  0         30h
ocnrf-nfdiscovery-94965d4fb9-rjxg3       1/1    Running  0         30h
ocnrf-nfregistration-64f4d8f5d5-6q92j    1/1    Running  0         30h
ocnrf-nfregistration-44f4d8f5d5-6q92i    1/1    Running  0         30h
ocnrf-nfsubscription-5b6db965b9-gcvpf    1/1    Running  0         30h
ocnrf-nfsubscription-4b6db965b9-gcvpe    1/1    Running  0         30h
ocnrf-nrfauditor-67b676dd87-xktbm        1/1    Running  0         30h
ocnrf-nrfconfiguration-678fddc5f5-c5htj  1/1    Running  0         30h