1. Cloud Native Core Console Installation and Upgrade Guide
  2. Installing CNC Console

3 Installing CNC Console

This section describes the prerequisites and installation procedure for the CNC Console.

CNC Console (cncc) helm chart is a common helm chart to be used for deploying Manager CNCC IAM (M-CNCC IAM), Manager CNCC Core (M-CNCC Core), and Agent CNCC Core (A-CNCC Core).

The package occncc_custom_configtemplates_<marketing-release-number>.zip consists of occncc_custom_values_<version>.yaml file and can be used for deployment of M-CNCC IAM, M-CNCC Core and A-CNCC Core.

This section covers installation instructions for M-CNCC IAM, M-CNCC Core and A-CNCC Core deployment.

Note:

  • For a single cluster deployment both manager (M-CNCC IAM, M-CNCC Core) and agent(A-CNCC Core) to be deployed on the same cluster.
  • For a multi cluster deployment if manager cluster has a local NF deployment then both manager(M-CNCC IAM, M-CNCC Core) and agent(A-CNCC Core) to be deployed on the same cluster. In case manager cluster do not have a local NF deployment then only manager(M-CNCC IAM, M-CNCC Core) to be deployed and agent(A-CNCC Core) to be deployed on a cluster where NFs are present on the cluster.
  • Manager manages CNE or OSO common service if present in a cluster.
    • Manager in a cluster is preferred over Agent in the same cluster to manage the CNE common services.
    • Agent in a cluster can manage CNE common service in absence of a Manager in the same cluster.
  • Agent is needed only when NFs are present on the cluster.

CNC Console Predeployment Configurations

Following are the predeployment configuration procedures:

Verifying and Creating CNC Console Namespace

This section explains how to verify or create new namespace in the system.

To create a namespace, perform the steps described in the procedure below:

Note:

To install CNC Console in NF specific namespace, replace cncc namespace with custom namespace.

To verify if the required namespace already exists in the system, run the following command:

$ kubectl get namespaces

If the namespace exists, you may continue with the next steps of installation.

If the required namespace is not available, create a namespace using the following command:

$ kubectl create namespace <required namespace>

Example:

$ kubectl create namespace cncc
Sample output:
 namespace/cncc created

Naming Convention for Namespaces

While choosing the name of the namespace where you wish to deploy CNC Console, make sure the following requirements are met:

  • starts and ends with an alphanumeric character
  • Contains a maximum of "63" characters
  • contains only alphanumeric characters or '-'

Note:

It is recommended to avoid using prefix kube- when creating namespace. This is required as the prefix is reserved for Kubernetes system namespaces.

Note:

For the information about extra privileges required to enable Debug tools, see the steps mentioned in the section CNCConsole Debug Tools.

Configuring Database

This section explains how database administrator can configure the databases.

Caution:

Verify the value of the following parameters, before deploying CNC Console on a cnDBTier 3 site georedundency setup:

ndb:

MaxNoOfOrderedIndexes: 1024

MaxNoOfTables: 1024

NoOfFragmentLogFiles: 512

If the values are not matching, see Oracle communications cnDBTier Installation Guide for details on how to update these parameters.

Configuring the Database User

This section explains how to create or verify the existing cncc user.

  1. Log in to the server or machine which has permission to access the SQL nodes of the NDB cluster.
  2. Connect to the SQL node of the NDB cluster or connect to the cnDbTier.

    Run the following command to connect to cnDbTier:

    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    Example:
    $ kubectl -n cndbtier  exec -it ndbmysqld-0 -c mysqlndbcluster -- bash
  3. Log in to the MySQL prompt using root permission or user, which has permission to create users with permissions.
    mysql -h 127.0.0.1 -u root -p

    Note:

    Provide MySQL password, when prompted.
  4. Check if CNCC user already exists by running the following command:
    $ SELECT User FROM mysql.user;
  5. If the user does not exist, create a cncc-user by running the following command:
    $ CREATE USER '<CNCC User Name>'@'%' IDENTIFIED BY '<CNCC Password>';
  6. Run the following command to grant NDB_STORED_USER permission to the cncc-user:
    $ GRANT NDB_STORED_USER ON *.* TO '<username>'@'%' WITH GRANT OPTION;
    Example:
    $ GRANT NDB_STORED_USER ON *.* TO 'cnccusr'@'%' WITH GRANT OPTION;
Configuring MySQL Secret

This section explains how to create and verify the kubernetes secret for MySQL.

  1. Run the following command to create the kubernetes secret for MySQL:
    
kubectl create secret generic <database secret name> --from-literal=dbUserNameKey=<CNCC MySQL database username> --from-literal=dbPasswordKey='<CNCC MySQL database passsword>' -n <Namespace of MySQL secret>
  2. Verify the secret created using following command:
    kubectl describe secret <database secret name> -n <Namespace of MYSQL secret>
    Example:
    
$ kubectl create secret generic cncc-db-secret --from-literal=dbUserNameKey=cnccusr --from-literal=dbPasswordKey='<db password>' -n cncc
$ kubectl describe secret cncc-db-secret -n cncc

Global Configurations

CNC Console Deployment Configurations

This section explains about the cncc global configurations which are common for M-CNCC IAM, M-CNCC Core, and A-CNCC Core deployment.

Table 3-1 CNC Console Deployment Configurations

Deployment isMultiClusterDeployment enabled cncc-iam enabled mcncc-core enabled acncc-core enabled
Single Cluster false true true true
Multi Cluster(manager only) true true true false
Multi Cluster(managing local NF’s) true true true true
Multi cluster(agent only) true false false true
Example: Configuration in occncc_custom_values_<version>.yaml file.

In case of single cluster deployment(global.isMultiClusterDeployment: false) the user must configure cncc-iam, mcncc-core and acncc-core flag to true. 


global:

  isMultiClusterDeployment: false

  cncc-iam:
    enabled: true
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true
CNC Console Configuration for Service Account
Global Service Account Configuration

CNC Console provides option to configure custom service account. Skip this, if already created as part of ASM configuration.

Sample CNCC service account yaml file

## Service account yaml file for cncc-sa
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-sa
  namespace: cncc
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  namespace: cncc
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  namespace: cncc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-sa
  namespace: cncc

Configure service account for ingress-gateway and keycloak in occncc_custom_values_<version>.yaml file as follows:

For Ingress Gateway and Keycloak provide custom service account under global.serviceAccountName.

global:
 
  serviceAccountName: &serviceAccountName cncc-sa
 
cncc-iam:
  kc:
    keycloak:
      serviceAccount:
        # The name of the service account to use.
        name: *serviceAccountName
Helm Test Service Account Configuration

Helm Test Service Account is an optional field. It should be added only if helm test kubernetes resource logging feature is enabled.

Custom service account can be provided for helm test in global.helmTestServiceAccountName: 

global:
 
  # ********    Sub-Section Start: Common Global Parameters        ********
  # ***********************************************************************
 
  helmTestServiceAccountName: cncc-helmtest-serviceaccount
Sample helm test service account : cncc-helmtest-serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-helmtest-serviceaccount
  namespace: cncc
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-helmtest-role
  namespace: cncc
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  - serviceaccounts
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - apps
  resources:
  - deployments
  - statefulsets
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - roles
  - rolebindings
  verbs:
  - get
  - watch
  - list
  - update
- apiGroups:
  - monitoring.coreos.com
  resources:
  - prometheusrules
  verbs:
  - get
  - watch
  - list
  - update
 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-helmtest-rolebinding
  namespace: cncc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-helmtest-role
subjects:
- kind: ServiceAccount
  name: cncc-helmtest-serviceaccount
  namespace: cncc

Note:

If user doesn't want to create the separate service account for helm test then also logging of resources and complaint check could be done using global service account . For that, required resources should be added to the global service account. For more details on helmTestserviceAccount, see Helm Test section.
Configuring ASM and OSO in CNC Console

For M-CNCC IAM ASM and OSO Configurations, see CNC Console Configuration to support ASM and OSO.

M-CNCC IAM Predeployment Configuration

The following are the predeployment configuration procedures of M-CNCC IAM:

Configuring M-CNCC IAM Database

This section explains how to create M-CNCC IAM Database and grant permissions to the CNC Console user for relevant operations on the Database.

Note:

CNCC Database Naming Convention

As the CNCC instances cannot share the same database, user must provide a unique name to the CNCC DB in the cnDBTier either limited to a site or spanning across sites.

The recommended format for database name is as follows: 
<database-name>_<site-name>_<cluster>
Example:
 cnccdb_site1_cluster1
While choosing the name of the database, make sure the following requirements are met:
  • starts and ends with an alphanumeric character
  • contains a maximum of 63 characters
  • contains only alphanumeric characters or '-'

    In this guide, the commands use "cnccdb" as sample database name. If a custom database name is used, user must use it in place of cnccdb.
  1. Log in to the server or machine with permission to access the SQL nodes of NDB cluster.
  2. Connect to the SQL node of the NDB cluster or connect to the cnDBTier.

    Run the following command to connect to the cnDBTier:

    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    Example:
    $ kubectl -n cndbtier  exec -it ndbmysqld-0 -c mysqlndbcluster -- bash
  3. Run the following command to log in to the MySQL prompt as a user with root permissions, which has permission to create users with permissions: 
    mysql -h 127.0.0.1 -u root -p

    Note:

    Enter the above command, and use the MYSQL password.
  4. Check if CNCC database already exists:
    1. Run the following command to check if database exists: 
      show databases;
    2. Run the following command to drop the existing cnccdb database: 
      DROP DATABASE <CNCC IAM Database>
      Example:
      DROP DATABASE cnccdb;
    3. Run the following command to create the Database:
      $ CREATE DATABASE IF NOT EXISTS <CNCC IAM Database>;
    4. Run the following command to grant permission to cncc-user:
    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, REFERENCES, INDEX, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON <M-CNCC IAM Database>.* TO'<CNCC IAM DB User Name>'@'%';
Example to demonstrate cnccdb creation, and granting permissions to cncc user: 

# Command to check if database exists:
$ show databases;
# Drop the existing cnccdb database:   
$ DROP DATABASE cnccdb;
# Database creation for CNCC:
$ CREATE DATABASE IF NOT EXISTS cnccdb;
#Granting permission to user:
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, REFERENCES, INDEX, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON cnccdb .* TO'cnccusr'@'%';
Configuring Secret for Default or Admin User in M-CNCC IAM

This section describes how to create kubernetes secret for default (admin) user.

  1. Run the following command to create the Kubernetes secret for admin user: 

    $ kubectl create secret generic <secret-name> --from-literal=iamAdminPasswordKey='<password>'--namespace <namespace>
    Example:
    
$ kubectl create secret generic cncc-iam-secret --from-literal=iamAdminPasswordKey='password' --namespace cncc
  2. Run the following command to verify the secret creation: 
    $ kubectl describe secret <secret name> -n <namespace>
    Example:
    
$ kubectl describe secret cncc-iam-secret -n cncc

Configuring Secret to Enable HTTPS in M-CNCC IAM

This section describes how create and configure secrets to enable HTTPS. This section must be run before Configuring Secret to Enable HTTPS CNCC Core Ingress Gateway.

Note:

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

Prerequisites to create kubernetes secret for HTTPS:

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

    CA Bundle creation

    When combining multiple CA certificates into a single certificate, add a delimiter after each certificate.

    Delimiter: "--------"

    Sample CA Bundle
    -----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----

Perform the following procedure to create the secrets to enable HTTPS after required certificates and password files are generated:

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

    Example:

    $ kubectl create secret generic cncc-iam-ingress-secret --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n cncc

    Note:

    Note down the command used during the creation of Kubernetes secret as this command is used for future updates.
  2. On successfully running the above command, the following message is displayed:

    secret/cncc-iam-ingress-secret created

  3. Run the following command to verify the secret creation: 
    $ kubectl describe secret cncc-iam-ingress-secret -n cncc

Perform the following procedure to update existing secrets to enable HTTPS, if they already exist:

  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of CNCC IAM Ingress Gateway secret> | kubectl replace -f --n <Namespace of CNCC IAM Ingress Gateway secret>

    Example:

    $ kubectl create secret generic cncc-iam-ingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n cncc | kubectl replace -f --n cncc
  2. On successfully running the above command, the following message is displayed:

    secret/cncc-iam-ingress-secret replaced

Dynamic Reloading of Certificates of M-CNCC IAM

Perform the following procedure for configuring CNC Console IAM to Support Dynamic Reloading of Certificates of M-CNCC IAM:

CNC Console supports Dynamic Reload of Certificates that are used to establish both TLS and mTLS connections.

To enable dynamic reloading of certificates, the following flags must be enabled in the occncc_custom_values_<version>.yaml file. 


cncc-iam:
 global:         
   ingressGwCertReloadEnabled: 
              &iamIGwCertReloadEnabled true

Note:

The new certificate must be created with the existing secret and certificate name.
The procedure for dynamic reloading of certificates as follows:
  1. Delete the existing certificates with which existing secure connections were established.
  2. Create the new certificate as per the requirement. The certificate must be created with the same name as the existing certificate.
  3. The Ingress Gateway pods automatically pick up the new certificates and the changes will be reflected in the browser.

Note:

Naming Update of Certificates and Secrets

If the name of the secret or the certificate is changed then the corresponding changes must be made in the occncc_custom_values_<version>.yaml file and either a reinstall or a helm upgrade must be done.

Configuring LDAPS in M-CNCC IAM

This section explains the procedure to enable LDAPS in M-CNCC IAM.

When you configure a secured connection URL to your LDAP store (Example: `ldaps://myhost.com:636'), CNCC IAM uses SSL for communication with the LDAP server. The truststore must be properly configured on the CNCC IAM server side; otherwise CNCC IAM cannot trust the SSL connection to LDAP.

For enabling LDAPS update kc section of occncc_custom_values_<version>.yaml as below: 

cncc-iam
               kc:  
                 ldaps:    
                     enabled: true

M-CNCC IAM Secret configuration for enabling LDAPS

Note:

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

To create Kubernetes secret for LDAPS, following files are required:

  • TrustStore password file
  • CA certificate or CA Bundle

Creating CA Bundle

When combining multiple CA certificates into a single certificate, add a delimiter after each certificate.

Delimiter: "--------"

Sample CA Bundle 

-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----

Note:

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

Perform the following procedure to create the secrets to enable LDAPS after required certificates and password files are generated and update details in kc section:

Note:

The value of ssl_truststore.txt and ssl_truststore-password-key value must be same.
  1. Run the following command to create secret: 
    kubectl create secret generic <secret-name> --from-file=<caroot.cer> --from-file=ssl_truststore.txt --from-literal=ssl_truststore-password-key=<password> --namespace cncc

    Note:

    Note down the command used during the creation of Kubernetes secret as this command is used for future updates.

    Example:

    $ kubectl create secret generic cncc-iam-kc-root-ca --from-file=caroot.cer --from-file=ssl_truststore.txt --from-literal=ssl_truststore-password-key=<password> --namespace cncc
    Run the following to display the sample ssl_truststore.txt:
    echo <password> > ssl_truststore.txt
  2. On successfully running the above command, the following message is displayed:

    secret/cncc-iam-kc-root-ca created

  3. Run the following command to verify the secret creation: 
    $ kubectl describe secret cncc-iam-kc-root-ca -n cncc

M-CNCC IAM Service Account configuration for enabling LDAPS

This section describes the customizations that you should make in custom-value.yaml file to configure Kubernetes service account. M-CNCC IAM provides option to configure custom service account.

Note:

Skip this section if service account is already configured as part of HTTPS or ASM configuration.

Configure service account for ingress-gateway and keycloak in custom-cncc_values_<version>.yaml as follows:

  1. For ingress-gateway provide custom service account under global.serviceAccountName.
    global:
 
  serviceAccountName: &serviceAccountName cncc-sa
 
cncc-iam:
  kc:
    keycloak:
      serviceAccount:
        # The name of the service account to use.
        name: *serviceAccountName

For CNCC IAM LDAP related configurations, see Integrating CNC Console LDAP Server with CNC Console IAM section in Oracle Communications Cloud Native Core Console User Guide.

Sample Service account section in custom-cncc_values_<version>.yaml:

## Service account yaml file for cncc-sa
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cncc-sa
  namespace: cncc
  annotations: {}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cncc-role
  namespace: cncc
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - watch
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cncc-rolebinding
  namespace: cncc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cncc-role
subjects:
- kind: ServiceAccount
  name: cncc-sa
  namespace: cncc

M-CNCC Core Predeployment Configuration

Following are the predeployment configuration procedures:

Configuring MySQL in M-CNCC Core

This section explains how to create M-CNCC Core database (mcncccommonconfig) and grant permissions to the M-CNCC Core database user for relevant operations on the mcncccommonconfig Database.

Note:

CNCC Common Config DB Naming Convention

As the CNCC instances cannot share the same database, operator has to provide a unique name to the M-CNCC Common Config DB in the cnDBTier either limited to a site or spanning across sites.

Format for database name for M-CNCC Core: 
<database-name>_<site-name>_<cluster>
Example database name:
 mcncccommonconfig_site1_cluster1
While choosing the name of the namespace, make sure the following requirements are met:
  • starts and ends with an alphanumeric character
  • Contains a maximum of 63 characters
  • contains only alphanumeric characters or '-'
In this installation guide, the commands use "mcncccommonconfig" as sample db name. The sample db name "mcncccommonconfig" must be replaced to the name chosen as per naming conventions defined by this note.
  1. Log in to the server or machine which has permission to access the SQL nodes of the NDB cluster.
  2. Connect to the SQL node of the NDB cluster or connect to the cnDBTier.

    Run the following command to connect to the cnDBTier:

    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    Example:
    $  kubectl -n occne-cndbtier  exec -it ndbmysqld-0 -c mysqlndbcluster -- bash
  3. Log in to the MySQL prompt using root permission or as a user with permission to create new users (with permissions). 
    $ mysql -h 127.0.0.1 -u root -p

    Note:

    After running the command mentioned above, user must enter MySQL password.
  4. Run the following command to check if Database mcncccommonconfig exists: 
    $ show databases;
  5. Run the following command to create a mcncccommonconfig, if the mcncccommonconfig does not exist:
    $ CREATE DATABASE IF NOT EXISTS <M-CNCC Common Config Database>;
  6. Run the following command to grant permission to cncc-user: 

    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, 
EXECUTE ON <M-CNCC Core Common Config Database>.* TO'<CNCC User Name>'@'%';
Example to demonstrate mcncccommonconfig creation, and granting permissions to cncc user: 

# Command to check if database exists:
$ show databases;
# Database creation for CNCC mcncccommonconfig if do not exists
$ CREATE DATABASE IF NOT EXISTS mcncccommonconfig;
# Granting permission to user:
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON mcncccommonconfig .* TO'cnccusr'@'%';
Configuring Secret to Enable HTTPS in M-CNCC Core

This section describes how to create secret configuration for enabling HTTPS. This section must be run before enabling HTTPS in CNCC Core Ingress Gateway.

Note:

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

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

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

    Note:

    For single cluster deployment, both M-CNCC Core and A-CNCC Core can use same configurations as both resides in same cluster namespace.

    Note:

    For multi cluster deployment configurations need to be created on both the clusters separately.

    CA Bundle creation

    When combining multiple CA certificates into a single certificate, add a delimiter after each certificate.

    Delimiter: "--------"

    Sample CA Bundle

    -----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----

Note:

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

This section explains how to create the secrets for enabling HTTPS after required certificates and password files are generated:

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

    Example:

    kubectl create secret generic cncc-core-ingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n cncc
    On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret created

    Note:

    Note down the command used during the creation of kubernetes secret, this command is used for updates in future.
  2. Run the following command to verify the secret creation: 
    $ kubectl describe secret cncc-core-ingress-secret -n cncc

Perform the following procedure to update existing secrets to enable HTTPS:

  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of M-CNCC Core Ingress Gateway secret> | kubectl replace -f - -n <Namespace of CNCC Core Ingress Gateway secret>

    Example:

    $ kubectl create secret generic cncc-core-ingress-secret --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n cncc | kubectl replace -f - -n cncc
  2. On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret replaced

Dynamic Reloading of Certificates of M-CNCC Core

CNC Console supports dynamic reloading of certificates that are used to establish both TLS and mTLS connections. To enable dynamic reloading of certificates, the following flags must be enabled in the occncc_custom_values_<version>.yaml file. 

mcncc-core:
  global:

       ingressGwCertReloadEnabled: & mcoreIGwCertReloadEnabled true

Note:

Here the new certificate must be created with the existing secret and certificate name.
The procedure for dynamic reloading of certificates as follows:
  1. Delete the existing certificates with which existing secure connections were established.
  2. Create the new certificate as per the requirement. The certificate must be created with the same name as the existing certificate.
  3. The IGW pods automatically pick up the new certificates and the changes will be reflected in the browser.

Note:

Naming update of Certificates and Secrets

If the name of the secret or the certificate is changed then the corresponding changes must be made in the occncc_custom_values_<version>.yaml file and either a reinstall or a helm upgrade must be done.

A-CNCC Core Predeployment Configuration

Following are the predeployment configuration procedures:

Configuring A-CNCC Core Database

This section explains how to create A-CNCC Core database (acncccommonconfig) and grant permissions to the A-CNCC Core database user for relevant operations on acncccommonconfig Database.

Note:

CNCC Common Config DB Naming Convention

As the CNCC instances cannot share the same database, operator has to provide a unique name to the CNCC Common Config DB in the cnDBTier either limited to a site or spanning across sites.

Format for database name: 
<database-name>_<site-name>_<cluster>
Example database name for A-CNCC Core:
 acncccommonconfig_site1_cluster1
While choosing the name of the namespace, make sure the following requirements are met:
  • starts and ends with an alphanumeric character
  • Contains a maximum of "63" characters
  • contains only alphanumeric characters or '-'
In this installation guide, the commands use "acncccommonconfig" as sample db name. The sample db name "cncccommonconfig" must be replaced to the name chosen as per naming conventions defined by this note.
  1. Log in to the server or machine which has permission to access the SQL nodes of the NDB cluster.
  2. Connect to the SQL node of the NDB cluster or connect to the cnDBTier.

    Run the following command to connect to the cnDBTier:

    
$ kubectl -n <cndbtier_namespace> exec -it <cndbtier_sql_pod_name> -c <cndbtier_sql_container_name> -- bash
    Example:
    $ kubectl -n occne-cndbtier  exec -it ndbmysqld-0 -c mysqlndbcluster -- bash
  3. Log in to the MySQL prompt using root permission or as a user with permissions to create users (with specific permissions). 
    $  mysql -h 127.0.0.1 -u root -p

    Note:

    After running the command mentioned above, user must enter MySQL password.
  4. Run the following command to check if Database acncccommonconfig exists: 
    $ show databases;
  5. Run the following command to create a acncccommonconfig, if the acncccommonconfig does not exist:
    $ CREATE DATABASE IF NOT EXISTS <A-CNCC Common Config Database>;
  6. Run the following command to grant permission to cncc-user: 

    $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, 
EXECUTE ON <A-CNCC Common Config Database>.* TO'<CNCC User Name>'@'%';
Example to demonstrate acncccommonconfig creation, and granting permissions to cncc user: 

# Command to check if database exists:
$ show databases;
# Database creation for CNCC acncccommonconfig if do not exists
$ CREATE DATABASE IF NOT EXISTS acncccommonconfig;
# Granting permission to user:
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON acncccommonconfig .* TO'cnccusr'@'%';
Configuring Secret to Enable HTTPS in A-CNCC Core

This section describes how to create secret configuration for enabling HTTPS. This section must be run before enabling HTTPS in A-CNCC Core Ingress Gateway.

Note:

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

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

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

    Note:

    For single cluster deployment, both M-CNCC Core and A-CNCC can use same configurations as both reside in same cluster namespace.

    Note:

    For multi cluster deployment configurations need to be created on both the clusters separately.

    CA Bundle creation

    When combining multiple CA certificates into a single certificate, add a delimiter after each certificate.

    Delimiter: "--------"

    Sample CA Bundle

    -----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----
--------
-----BEGIN CERTIFICATE-----
MIID4TCC...
...
...jtUl/zQ==
-----END CERTIFICATE-----

Note:

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

This section explains how to create the secrets for enabling HTTPS after required certificates and password files are generated:

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

    Example:

    kubectl create secret generic cncc-core-ingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n cncc

    Note:

    Note down the command used during the creation of Kubernetes secret, this command is used for updating the secrets in future.
    On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret created

  2. Run the following command to verify the secret creation:

    $ kubectl describe secret cncc-core-ingress-secret -n cncc

Perform the following procedure to update existing secrets to enable HTTPS:

  1. Run the following command to create secret:
    $ kubectl create secret generic <secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of CNCC Core Ingress Gateway secret> | kubectl replace -f - -n <Namespace of CNCC Core Ingress Gateway secret>

    Example:

    $ kubectl create secret generic cncc-core-ingress-secret --from-file=ssl_ecdsa_private_key.pem  --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-fileS=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n cncc | kubectl replace -f - -n cncc
  2. On successfully running the above command, the following message will be displayed:

    secret/cncc-core-ingress-secret replaced

Dynamic Reloading of Certificates of A-CNCC Core

CNC Console supports dynamic reloading of certificates that are used to establish both TLS and mTLS connections. To enable dynamic reloading of certificates, the following flags must be enabled in the occncc_custom_values_<version>.yaml file. 


acncc-core:
  global:         
     ingressGwCertReloadEnabled: &acoreIGwCertReloadEnabled true

Note:

Here the new certificate must be created with the existing secret and certificate name.
The procedure for dynamic reloading of certificates as follows:
  1. Delete the existing certificates with which existing secure connections were established.
  2. Create the new certificate as per the requirement. The certificate must be created with the same name as the existing certificate.
  3. The IGW pods automatically pick up the new certificates and the changes will be reflected in the browser.

Note:

Naming update of Certificates and Secrets

If the name of the secret or the certificate is changed then the corresponding changes must be made in the occncc_custom_values_<version>.yaml file and either a reinstall or a helm upgrade must be done.

Configuring A-CNCC Core mTLS

This section describes the A-CNCC Core Configuration for enabling mTLS.

mTLS Configuration at A-CNCC Core

mTLS must be enabled at the ingress-gateway SSL configuration section of the A-CNCC Core occncc_custom_values_<version>.yaml file. The parameter scheme must be set to https in the occncc_custom_values_<version>.yaml file.

Sample TLS Configuration section of A-CNCC Core:

acncc-core:
  global
    # CNCC https enabled
    httpsEnabled: &httpsEnabled true
    # Server Configuration for http and https support
    enableIncomingHttp: &enableIncomingHttp false
    enableIncomingHttps: &enableIncomingHttps true
    # Enables server with MTLS
    needClientAuth: &needClientAuth true

Note:

While enabling mTLS, needClientAuth must be set to true in A-CNCC Core.

Deploying CNC Console

This section provides installation procedures to install CNC Console using Command Line Interface (CLI). To install CNC Console using CDCS, see Oracle Communications Cloud Native Core CD Control Server User Guide.

Perform the following procedure to deploy CNC Console:
  1. Run the following command to check the version of the helm chart installation: 
    helm search repo <release_name> -l
    Example:
     helm search repo cncc -l
    NAME             CHART VERSION  APP VERSION  DESCRIPTION
ocspf-helm-repo/cncc      22.3.2         22.3.2     A Helm chart for CNC Console
  2. Prepare the occncc_custom_values_<version>.yamlfile with the required parameter information. For configuring custom-cncc_values.yaml file, see CNC Console Configuration Parameters section.

    Note:

    The annotation metallb.universe.tf/address-pool: signaling/oam is required in global section if MetalLB in CNE 1.8.x onwards is used.
    
customExtension:
  lbServices:
    labels: {}
    annotations:
     # The annotation metallb.universe.tf/address-pool: signaling/oam is required if MetalLB in CNE 1.8.x is used
      metallb.universe.tf/address-pool: oam
      service.beta.kubernetes.io/oci-load-balancer-internal: "true"

    Note:

    The annotation oracle.com.cnc/app-protocols: '{"http2-tls":"TCP"}' is required in global section of custom-cncc-iam_values.yaml file when CNC Console is deployed with HTTPs enabled in CNE.
    customExtension:
  lbServices:
    labels: {}
    annotations:
      oracle.com.cnc/app-protocols: '{"http2-tls":"TCP"}'

    Following configurations are needed in occncc_custom_values_<version>.yaml file. This includes configuring the following based on the deployment:

    1. Update unique CNCC ID per cluster (global.self.cnccId )
    2. Provide the details of M-CNCC IAMs (mCnccIams)
    3. Provide the details of A-CNCC (aCnccs)
    4. Provide the details of Agent Instances (instances)
    5. In case of M-CNCC Core, additionally provide the details of M-CNCC Cores and M-CNCC Instances (instances)

    Note:

    • For instances configuration details see, CNC Console Instances Configurations section and section CNC Console Instances Configuration Options section.

    • There are multiple M-CNCC, A-CNCC, NF Instances, and OCCNE Instances. So, be cautious while updating coccncc_custom_values_<version>.yaml file.

    • In case of M-CNCC Core, cmservice.envSystemName in occncc_custom_values_<version>.yaml file can be used to display cluster name.

      Example: envSystemName: CNCC - Site Name

    • Routes creation happens automatically, there is no need to provide routes in the ingress-gateway section; only instances details have to be provided in global section.

      A-CNCC and M-CNCC Core uses same cncc helm chart, only deployment configurations may differ.
    • See CNC Console Deployment Configuration Workflow section for details on deployment specific configuration updates CNC Console Deployment Configuration Workflow.

  3. The following are the Sample configuration section for CNCC:
    1. Single Cluster Deployment

      Sample configuration section for CNCC in case of single cluster deployment

      global:
 
  cncc-iam:
    enabled: true
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true
 
  isMultiClusterDeployment: false
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster1
      role: Cluster1
      fqdn: cncc-acore-ingress-gateway.cncc.svc.bumblebee
      port: 80
  instances:
    - id: Cluster1-grafana
      type: CS
      owner: Cluster1
      fqdn: occne-kube-prom-stack-grafana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/grafana
    - id: Cluster1-kibana
      type: CS
      owner: Cluster1
      fqdn: occne-kibana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/kibana
    - id: Cluster1-scp-instance1
      type: SCP
      owner: Cluster1
      fqdn: ocscp-scpc-configuration.scp.svc.bumblebee
      port: 80
    2. Multi Cluster Deployment

      Sample configuration section for manager only deployment set cncc-iam, mcncc-core to "true" and acncc-core to "false".

      global:
    
  cncc-iam:
    enabled: true  
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: false
    
  isMultiClusterDeployment: true    
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx    
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster2
      role: Cluster2
      ip: 10.xx.xx.xx
      port: 80
  instances:
    - id: Cluster1-grafana
      type: CS
      owner: Cluster1
      fqdn: occne-kube-prom-stack-grafana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/grafana
    - id: Cluster1-kibana
      type: CS
      owner: Cluster1
      fqdn: occne-kibana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/kibana
    - id: Cluster2-kibana
      type: CS
      owner: Cluster2
      fqdn: occne-kibana.occne-infra.svc.jazz
      apiPrefix: /jazz/kibana
    - id: Cluster2-scp-instance2
      type: SCP
      owner: Cluster2      
      fqdn: ocscp-scpc-configuration.scp.svc.jazz      
      port: 80
    Sample configuration section for manager managing local NFs. User must configure cncc-iam, mcncc-core and acncc-core flag to "true".
    global:
  
  cncc-iam:
    enabled: true
  mcncc-core:
    enabled: true
  acncc-core:
    enabled: true
    
  isMultiClusterDeployment: true  
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx  
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster1
      role: Cluster1
      fqdn: cncc-acore-ingress-gateway.cncc.svc.bumblebee
      port: 80   
    - id: Cluster2
      role: Cluster2
      ip: 10.xx.xx.xx
      port: 80
  instances:     
    - id: Cluster1-grafana
      type: CS
      owner: Cluster1
      fqdn: occne-kube-prom-stack-grafana.occne-infra.svc.bumblebee      
      apiPrefix: /bumblebee/grafana
    - id: Cluster1-kibana
      type: CS
      owner: Cluster1
      fqdn: occne-kibana.occne-infra.svc.bumblebee
      apiPrefix: /bumblebee/kibana
    - id: Cluster1-scp-instance1
      type: SCP
      owner: Cluster1      
      fqdn: ocscp-scpc-configuration.scp.svc.bumblebee      
      port: 80
    - id: Cluster2-scp-instance2
      type: SCP
      owner: Cluster2       
      fqdn: ocscp-scpc-configuration.scp.svc.jazz       
      port: 80

    Sample configuration section for agent only deployment. User must configure cncc-iam and mcncc-core to "false" and acncc-core to "true".

    global:
  
  cncc-iam:
    enabled: false
  mcncc-core:
    enabled: false
  acncc-core:
    enabled: true
    
  isMultiClusterDeployment: true  
  # Automatic route generation for CNCC Manager Deployment
  self:
    cnccId: Cluster2
  mCnccIams:
    - id: Cluster1
      ip: 10.xx.xx.xx  
  mCnccCores:
    - id: Cluster1
  aCnccs:
    - id: Cluster2
      role: Cluster2
  instances:     
    - id: Cluster2-kibana
      type: CS
      owner: Cluster2
      fqdn: occne-kibana.occne-infra.svc.jazz
      apiPrefix: /jazz/kibana
    - id: Cluster2-scp-instance2
      type: SCP
      owner: Cluster2      
      fqdn: ocscp-scpc-configuration.scp.svc.jazz       
      port: 80

    Note:

    • In the above examples, mCnccIams port is assumed as "80". The mCnccIams port configuration must be added only if port value is other than "80".
    • Instance id must be globally unique as it will be used for routing, here is the recommendation for id naming
    • id: <owner>-<instance name>

      Example:

      id: Cluster2-scp-instance2

    • aCnccs.id:
      • is mandatory as its needed for site authorization
      • aCnccs.id value must be same as self.cnccId
      • aCnccs.role and mCnccCores.role are optional, which can be used for overriding site role name.
    • For HTTPS enabled deployment scheme and port has to be updated to "https" and "https port value" in mCnccIams and aCnccs. For sample configuration, see CNCC Core InstancesConfiguration examples listed in appendix.
  4. Deploy M-CNCC IAM using repository and helm tar.

    Caution:

    The CNCC helm install command may take longer than usual time to run because the kubernetes job runs through install helm hook. Helm deployment status is shown as DONE after the applicable hook is run.

    Caution:

    Pod restarts maybe observed at M-CNCC Core ingress-gateway during fresh installation, upgrade, or rollback. This is because M-CNCC Core ingress-gateway internally check if CNCC IAM KC pod is up or not via CNCC IAM ingress-gateway. Once CNCC IAM KC pod is up then you should see M-CNCC Core ingress-gateway in running state.

    To verify the deployment status, open a new terminal and run the following command:

    kubectl get pods -n <namespace_name> -w
    Example: 
    kubectl get pods -n cncc -w

    The pod status gets updated on a regular interval. When helm install command is run and exits with the status, you may stop watching the status of Kubernetes pods.

    Note:

    If helm purge do not clean the deployment and Kubernetes objects completely, then follow CNC Console IAM Clean up section.
    Update DB details in occncc_custom_values_<version>.yaml file.
    
dbVendor: mysql   
dbName: cnccdb
dbHost: mysql-sds.default.svc.cluster.local
dbPort: 3306

    Note:

    Database must be created first and that Database name must be mentioned as dbName.
    1. Run the following command for installing using helm repository: 

      
helm install <release_name> <helm-repo> -f occncc_custom_values_22.3.2.yaml --namespace <namespace_name> --version <helm_version>

      Where:

      helm-repo: repository name where the helm images, charts are stored

      values: helm configuration file which needs to be updated based on the docker registry

      release_name and namespace_name: depends on customer configuration

      Example:

      

helm install cncc ocscp-helm-repo/cncc -f occncc_custom_values_22.3.2.yaml --namespace cncc --version 22.3.2

    2. Run the following command for Installing using helm tar: 

    

helm install cncc -f occncc_custom_values_22.3.2.yaml --namespace <namespace> <chartpath>./<chart>.tgz

    Example:

    helm install cncc -f occncc_custom_values_22.3.2.yaml --namespace cncc occncc-22.3.2.tgz

  5. Run the following commands to upgrade the CNCC Configuration:

    Note:

    For details about CNC Console Deployment Configuration workflow, see CNC Console Deployment Configuration Workflow section.
    You have to do the following steps for upgrade:
    • Prepare the occncc_custom_values_<version>.yaml file for upgrade
    • Upgrade CNCC
    1. Run the following command for upgrading using helm repository:
      $ helm3 upgrade <release_name> <helm_chart> -f <occncc_custom_values_<version>.yaml> --namespace <namespace-name>
      Example:
      $ helm3 upgrade cncc ocspf-helm-repo/cncc -f occncc_custom_values_22.3.2.yaml --namespace cncc
    2. Run the following command for upgrading using helm tar:
      helm  upgrade cncc -f occncc_custom_values_<version>.yaml --namespace <namespace> <chartpath>./<chart>.tgz
      Example:
      helm  upgrade cncc -f occncc_custom_values_22.3.2.yaml --namespace cncc occncc-22.3.2s.tgz
  6. Run the following command to check the deployment status: 
    helm status <release_name>
  7. Run the following command to check if all the services are deployed and running: 
    kubectl -n <namespace_name> get services

    Example:

    $ kubectl -n cncc get services
    Example:
    NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                      AGE
cncc-acore-cmservice         ClusterIP      10.233.41.221   <none>           8442/TCP                     24h
cncc-acore-igw-cache         ClusterIP      None            <none>           8000/TCP                     24h
cncc-acore-ingress-gateway   ClusterIP      10.233.47.246   <none>           80/TCP                       24h
cncc-iam-igw-cache           ClusterIP      None            <none>           8000/TCP                     24h
cncc-iam-ingress-gateway     LoadBalancer   10.233.3.123    10.75.224.188    80:30185/TCP                 24h
cncc-iam-kc-headless         ClusterIP      None            <none>           8285/TCP                     24h
cncc-iam-kc-http             ClusterIP      10.233.42.16    <none>           8285/TCP,8443/TCP,9990/TCP   24h
cncc-mcore-cmservice         ClusterIP      10.233.9.144    <none>           8442/TCP                     24h
cncc-mcore-igw-cache         ClusterIP      None            <none>           8000/TCP                     24h
cncc-mcore-ingress-gateway   LoadBalancer   10.233.44.167   10.75.224.189    80:30175/TCP                 24h
  8. Run the following command to check if all the pods are up and running: 
     kubectl -n <namespace_name> get pods

    Example:

    $ kubectl -n cncc get pods
    Example:
    
NAME                                         READY   STATUS    RESTARTS        AGE
cncc-acore-cmservice-8699559488-jxwwt        1/1     Running   0               24h
cncc-acore-ingress-gateway-c685bf678-bgmdf   1/1     Running   0               24h
cncc-iam-ingress-gateway-6776df55cd-xzx2m    1/1     Running   0               24h
cncc-iam-kc-0                                2/2     Running   0               24h
cncc-mcore-cmservice-587749d58d-8lnd7        1/1     Running   0               24h
cncc-mcore-ingress-gateway-59758876b-zc7d7   1/1     Running   0               24h

Caution:

Do not exit from helm install command manually. After running the helm install command, it will take a while to install all the services. This is because during installation Kubernetes jobs are initiated by helm hooks. For verifying the installation status, see Verifying CNC Console IAM Installation.

Note:

timeout duration (optional): If not specified, the default value will be 5m (5 minutes) in Helm3. Specifies the time to wait for any individual Kubernetes operation (like Jobs for hooks). The default value is 5m0s. If the helm install command fails at any point to create a Kubernetes object, it will internally call the purge to delete after timeout value (default: 300s). Here timeout value is not for overall install, but it is for automatic purge on installation failure.

Verifying CNC Console Installation

This section describes how to verify if CNC Console is installed successfully.

  1. To check the installation status, run the following command:
    helm ls -n <release-namespace>
    For example:
    helm ls -n cncc

    You should see the status as DEPLOYED if the deployment is successful.

  2. To get the status of jobs and pods, run the following command:
    kubectl get jobs,pods -n release_namespace
    For example:
    kubectl get pod -n cncc

    You should see the status as Running and Ready for all the pods if the deployment is successful.

  3. Run the following command to check the status of the services: 
    kubectl get services -n release_namespace
    For example: 
    kubectl get services -n cncc

Note:

Take a backup of the following files that are required during disaster recovery:

  • Updated occncc_custom_values_<version>.yaml file
  • Updated helm charts
  • secrets, certificates, and keys that are used during installation

Note:

If the installation is not successful or you do not see the status as Running for all the pods, perform the troubleshooting steps provided in Oracle Communications Cloud Native Core Console Troubleshooting Guide.

CNC Console Microservices

This section provides the details of CNC Console microservices.

M-CNCC IAM Microservices

M-CNCC IAM has the microservices which are responsible for Identity Access Management:

The following is an example of services CNC Console IAM offers:

Table 3-2 CNC Console IAM Microservices

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cncc-iam-kc-headless ClusterIP None <none> 8285/TCP 9m13s
cncc-iam-kc-http ClusterIP 10.233.25.75 <none> 8285/TCP 9m13s
cncc-iam-ingress-gateway LoadBalancer 10.233.7.236 10.75.182.72 8080:30346/TCP 9m13s
cncc-iam-cncc-iam-igw-cache ClusterIP None <none> 8000/TCP 9m13s

Note:

cncc-iam-cncc-iam-igw-cache is an ingress gateway coherence service which is enabled by default by ingress-gateway chart. CNC Console IAM does not use this feature.

M-CNCC Core Microservices

M-CNCC Core has two microservices:

  1. cncc-mcore-ingress-gateway: cncc-mcore-ingress-gateway is responsible to redirect the request to either producer NF or CNCC Core GUI.
  2. cncc-mcore_cmservice: cncc-mcore_cmservice is responsible for displaying CNCC Core GUI.

Following is an example of services M-CNCC Core offers:

Table 3-3 M-CNCC Core Microservices

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cncc-mcore-cmservice ClusterIP 10.108.119.182 <none> 8442/TCP 24h
cncc-mcore-igw-cache ClusterIP None <none> 8000/TCP 24h
cncc-mcore-ingress-gateway LoadBalancer 10.103.6.17 <pending> 8080:31417/TCP 24h

A-CNCC Core Microservices

A-CNCC Core has the following microservices:

  1. cncc-acore-ingress-gateway: cncc-acore-ingress-gateway is responsible to redirect the request to either producer NF or CNCC Core GUI.
  2. cncc-acore_cmservice: cncc-acore_cmservice is responsible for displaying CNCC Core GUI.

Following is an example of services A-CNCC Core offers:

Table 3-4 A-CNCC Core Microservices

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cncc-acore-cmservice ClusterIP 10.106.93.165 <none> 8442/TCP 24h
cncc-acore-cncc-core-igw-cache ClusterIP None <none> 8000/TCP 24h
cncc-acore-ingress-gateway ClusterIP 10.105.11.175 <none> 8080/TCP 24h

Note:

cncc-acore-igw-cache is an ingress gateway coherence service which is enabled by default by ingress-gateway helm chart, CNC Console Core does not use this feature.