2 Installing Cloud Native Core Policy
This chapter describes how to install Cloud Native Core Policy on a cloud native environment.
Pre-Installation Tasks
In this release, Single Release Bundle provides the following deployment models:
- Converged Deployment
- PCF Deployment
- CNPCRF Deployment
Prior to installing the Cloud Native Core Policy (CNC Policy), perform the following tasks:
Checking the Software Requirements
Note:
In this release, Cloud Native Core Policy supports Oracle Communications Cloud Native Environment (OCCNE) 1.5.echo $OCCNE_VERSION
Note:
In this release, Cloud Native Core Policy supports Aspen Service Mesh 1.4.Software | Version |
---|---|
Kubernetes | v1.16.7 |
HELM | v3.0 |
kubectl version
helm3 version
Additional software that needs to be deployed as per the requirement of the services:
Software | App Version | Notes |
---|---|---|
alertmanager | 0.20.0 | Required for Tracing |
elasticsearch | 7.6.1 | Required for Logging |
elastic-curator | 2.0.2 | Required for Logging |
elastic-exporter | 1.1.2 | Required for Logging |
logs | 2..7.0 | Required for Logging |
kibana | 7.6.1 | Required for Logging |
grafana | 5.0.5 | Required for Metrics |
prometheus | 11.0.2 | Required for Metrics |
prometheus-node-exporter | 1.9.0 | Required for Metrics |
metallb | 0.12.0 | Required for External |
metrics-server | 2.10.0 | Required for Metric Server |
occne-snmp-notifier | 0.2.0 | Required for Metric Server |
tracer | 0.13.3 | Required for Tracing |
Note:
The above softwares are available if the Cloud Native Core Policy (CNC Policy) is deployed in the Oracle Communications Cloud Native Environment (OCCNE). If you are deploying Cloud Native Core Policy (CNC Policy) in any other environment, the above softwares must be installed before installing the Cloud Native Core Policy (CNC Policy). To check the installed software items,helm ls
Some of the systems may
need to use helm command with admin.conf file as follows:
helm --kubeconfig admin.conf
Note:
If you are using Network Repository Function (NRF), install it before proceeding with the Core Policy (CNC Policy) installation. CNC Policy 1.8.1 supports NRF 1.8.Checking the Environment Setup
Note:
This section is applicable only when the Cloud Native Core Policy (CNC Policy) is deployed in the environment, other than OCCNE.Network access
The Kubernetes cluster hosts must have network access to:
- Local helm repository, where the Cloud
Native Core Policy (CNC Policy) helm charts are available.
To check if the Kubernetes cluster hosts have network access to the local helm repository, execute the following command:
helm repo update
Note:
Some of the systems may need to use helm command with admin.conf file as follows:helm --kubeconfig admin.conf
- Local docker image repository, where
the Cloud Native Core Policy (CNC Policy) images are available.
To check if the Kubernetes cluster hosts have network access to the local docker image repository, pull any image with tag name to check connectivity by executing the following command:
where:docker pull docker-repo/image-name:image-tag
docker-repo is the IP address or host name of the repository.
image-name is the docker image name.
image-tag is the tag the image used for the Cloud Native Core Policy (CNC Policy) pod.
Note:
All the kubectl and helm related commands that are used in this guide must be executed on a system depending on the infrastructure/deployment. It could be a client machine, such as, a VM, server, local desktop, and so on.Client Machine Requirements
Following are the client machine requirements where the deployment commands executed:- It should have network access to the helm repository and docker image repository.
- It should have network access to the Kubernetes cluster.
- It should have necessary environment settings to
run the
kubectl
anddocker
commands. The environment should have privileges to create namespace in the Kubernetes cluster. - It should have helm client installed
with the push plugin. 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 enabling HTTPs on Ingress/Egress gateway the following certificates and pem files has to be created before creating secret files for keys:
- ECDSA private Key and CA signed ECDSA Certificate (if initialAlgorithm: ES256)
- RSA private key and CA signed RSA Certificate (if initialAlgorithm: RSA256)
- TrustStore password file
- KeyStore password file
- CA signed ECDSA certificate
Installation Tasks
Downloading Cloud Native Core Policy (CNC Policy) package
CNC Policy 1.8.0 package can be downloaded from Oracle Software Delivery Cloud (OSDC)/My Oracle Support (MOS).
- Login to My Oracle Support with your credentials.
- Select Patches and Updates tab to locate the patch.
- In Patch Search window, click Product or Family (Advanced).
- Enter "Oracle Communications Cloud Native Core - 5G" in Product field, select "Oracle Communications Cloud Native Core Policy 1.8.0.0.0" from Release drop-down.
- Click Search. The Patch Advanced Search Results displays a list of releases.
- Select the required patch from the search results. The Patch Details window opens.
- Click Download. File Download window appears.
- Click the <p********_<release_number>_Tekelec>.zip file to downlaod the CNC Policy package file.
- Login to Oracle Software Delivery Cloud with your credentials.
- Enter "Oracle Communications Cloud Native Core - 5G" and click
Search
"REL: Oracle Communications Cloud Native Core Policy 1.8.0.0.0" will be listed as shown below, click Select.
- Selected item will be added in the list, click Continue.
- Accept the license agreement and click Continue.
- Click Download.
This will install download manager and then provide the path where to download CNC Policy package, download manager will download the CNC Policy Package 1.8.0.0.0.
Pushing the Images to Customer Docker Registry
- Untar the Cloud Native Core Policy (CNC Policy) package zip file
to get Cloud Native Core Policy (CNC Policy) docker image tar file.
The directory consists of the following:tar -xvzf occnp-pkg-1.8.0.0.0tgz
- Cloud Native Core Policy (CNC Policy) Docker Images
File:
occnp-images-1.8.0.tar
- Helm File:
occnp-1.8.0.tgz
- Readme txt File:
Readme.txt
- Checksum for Helm chart tgz file:
occnp-1.8.0.tgz.sha256
- Checksum for images' tgz file:
occnp-images-1.8.0.tar.sha256
- Cloud Native Core Policy (CNC Policy) Docker Images
File:
-
Load the occnp-images-1.8.0.tar file into the Docker system
docker load --input /IMAGE_PATH/occnp-images-1.8.0.tar
- Verify that the image is loaded correctly by entering this
command:
Refer Docker Images for more information on docker images available in Cloud Native Core Policy (CNC Policy).docker images
- Create a new tag for each imported image and push the image to the customer
docker registry by entering this command:
where:docker tag occnp/oc-app-info:1.8.0 CUSTOMER_REPO/oc-app-info:1.8.0 docker push CUSTOMER_REPO/oc-app-info:1.8.0 docker tag occnp/oc-policy-ds:1.8.0 CUSTOMER_REPO/oc-policy-ds:1.8.0 docker push CUSTOMER_REPO/oc-policy-ds:1.8.0 docker tag occnp/alternate_route:1.0.1 CUSTOMER_REPO/alternate_route:1.0.1 docker push CUSTOMER_REPO/alternate_route:1.0.1 docker tag occnp/ocingress_gateway:1.8.1 CUSTOMER_REPO/ocingress_gateway:1.8.1 docker push CUSTOMER_REPO/ocingress_gateway:1.8.1 docker tag occnp/oc-pcf-sm:1.8.0 CUSTOMER_REPO/oc-pcf-sm:1.8.0 docker push CUSTOMER_REPO/oc-pcf-sm:1.8.0 docker tag occnp/oc-pcf-am:1.8.0 CUSTOMER_REPO/oc-pcf-am:1.8.0 docker push CUSTOMER_REPO/oc-pcf-am:1.8.0 docker tag occnp/oc-pcf-ue:1.8.0 CUSTOMER_REPO/oc-pcf-ue:1.8.0 docker push CUSTOMER_REPO/oc-pcf-ue:1.8.0 docker tag occnp/oc-audit:1.8.0 CUSTOMER_REPO/oc-audit:1.8.0 docker push CUSTOMER_REPO/oc-audit:1.8.0 docker tag occnp/oc-ldap-gateway:1.8.0 CUSTOMER_REPO/oc-ldap-gateway:1.8.0 docker push CUSTOMER_REPO/oc-ldap-gateway:1.8.0 docker tag occnp/oc-query:1.8.0 CUSTOMER_REPO/oc-query:1.8.0 docker push CUSTOMER_REPO/oc-query:1.8.0 docker tag occnp/oc-pre:1.8.0 CUSTOMER_REPO/oc-pre:1.8.0 docker push CUSTOMER_REPO/oc-pre:1.8.0 docker tag occnp/oc-perf-info:1.8.0 CUSTOMER_REPO/oc-perf-info:1.8.0 docker push CUSTOMER_REPO/oc-perf-info:1.8.0 docker tag occnp/oc-diam-gateway:1.8.0 CUSTOMER_REPO/oc-diam-gateway:1.8.0 docker push CUSTOMER_REPO/oc-diam-gateway:1.8.0 docker tag occnp/oc-diam-connector:1.8.0 CUSTOMER_REPO/oc-diam-connector:1.8.0 docker push CUSTOMER_REPO/oc-diam-connector:1.8.0 docker tag occnp/oc-pcf-user:1.8.0 CUSTOMER_REPO/oc-pcf-user:1.8.0 docker push CUSTOMER_REPO/oc-pcf-user:1.8.0 docker tag occnp/oc-config-mgmt:1.8.0 CUSTOMER_REPO/oc-config-mgmt:1.8.0 docker push CUSTOMER_REPO/oc-config-mgmt:1.8.0 docker tag occnp/oc-config-server:1.8.0 CUSTOMER_REPO/oc-config-server:1.8.0 docker push CUSTOMER_REPO/oc-config-server:1.8.0 docker tag occnp/ocegress_gateway:1.8.1 CUSTOMER_REPO/ocegress_gateway:1.8.1 docker push CUSTOMER_REPO/ocegress_gateway:1.8.1 docker tag occnp/nrf-client:1.3.0 CUSTOMER_REPO/nrf-client:1.3.0 docker push CUSTOMER_REPO/nrf-client:1.3.0 docker tag occnp/oc-readiness-detector:1.8.0 CUSTOMER_REPO/oc-readiness-detector:1.8.0 docker push CUSTOMER_REPO/oc-readiness-detector:1.8.0 docker tag occnp/configurationinit:1.4.0 CUSTOMER_REPO/configurationinit:1.4.0 docker push CUSTOMER_REPO/configurationinit:1.4.0 docker tag occnp/configurationupdate:1.4.0 CUSTOMER_REPO/configurationupdate:1.4.0 docker push CUSTOMER_REPO/configurationupdate:1.4.0 docker tag occnp/oc-soap-connector:1.8.0 CUSTOMER_REPO/occnp/oc-soap-connector:1.8.0 docker push CUSTOMER_REPO/occnp/oc-soap-connector:1.8.0 docker tag occnp/oc-pcrf-core:1.8.0 CUSTOMER_REPO/occnp/oc-pcrf-core:1.8.0 docker push CUSTOMER_REPO/occnp/oc-pcrf-core:1.8.0 docker tag occnp/oc-binding:1.8.0 CUSTOMER_REPO/occnp/oc-binding:1.8.0 docker push CUSTOMER_REPO/occnp/oc-binding:1.8.0
CUSTOMER_REPO is the docker registry address having Port Number, if registry has port attached.
Note:
For OCCNE, copy the package to bastion server and use localhost:5000 as CUSTOMER_REPO to tag the images and push to bastion docker registry.Note:
You may need to configure the Docker certificate before the push command to access customer registry via HTTPS, otherwise, docker push command may fail.
Configuring Database, Creating Users, and Granting Permissions
Cloud Native Core Policy (CNC Policy) microservices use MySQL database to store the configuration and run time data. Following microservices require dedicated MySQL databases created in MySQL data tier.
- Session Management (SM) Service - To store SM and Policy Authorization (PA) session state
- Access and Mobility (AM) Service - To store AM session state
- User Service - To store user information like Policy Data (from UDR) and Policy Counter information (from CHF)
- Config Server - To store configuration data
- Audit Service - To store session state audit data
- PCRF Core service - To store Gx session, Rx Session and User Profile information
- Binding Service - To store context binding information of 4g and 5g subscribers
The CNC Policy requires the database administrator to create user in MySQL DB and provide necessary permissions to access the databases. Before installing the CNC Policy it is required that the MySQL user and databases are created.
Each microservice has a default database name assigned as mentioned in below table:Service Name | Default Database Name | Applicable to Deployment |
---|---|---|
SM Service | occnp_pcf_sm | PCF (if smServiceEnable parameter is enabled in custom yaml file.) |
AM Service | occnp_pcf_am | PCF (if amServiceEnable parameter is enabled in custom yaml file.) |
User Service | occnp_pcf_user | PCF (mandatory) |
Config Server Service | occnp_config_server | cnPCRF & PCF (mandatory) |
Audit Service | occnp_audit_service | PCF (if enabled) |
PCRF Core Service | occnp_pcrf_core | cnPCRF (if pcrfCoreEnable parameter is enabled in custom yaml file.) |
Binding Service | occnp_binding | cnPCRF & PCF (if bindingEnable parameter is enabled in custom yaml file.) |
Note:
This database name is specified in the releaseDbName parameter in the custom-value.yaml file.It is recommended to use unique database name when there are multiple instances of CNC Policy deployed in the network and they share the same data tier (MySQL cluster).
It is recommended to create custom unique database name, by simply prefixing the deployment name of the CNC Policy. This way database name uniqueness can be achieved across all deployments. However, you can use any prefix/suffix to create the unique database name. For example, if the OCPCF deployment name is "site1" then the SM Service database can be named as "occnp_pcf_sm_site1".
Refer the Database Name Configuration section for how to override default database names with custom database names.
To configure MYSQL database for the different microservices:
- Login to the server where the ssh keys are stored and SQL nodes are accessible.
- Connect to the SQL nodes.
- Login to the database as a root user.
- Create database for the different
microservices:
CREATE DATABASE occnp_audit_service; CREATE DATABASE occnp_config_server; CREATE DATABASE occnp_pcf_am; CREATE DATABASE occnp_pcf_sm; CREATE DATABASE occnp_pcf_user; CREATE DATABASE occnp_pcrf_core; CREATE DATABASE occnp_release; CREATE DATABASE occnp_binding;
- Create an admin user and grant all the necessary permissions to the user by
executing the following
command:
CREATE USER 'username'@'%' IDENTIFIED BY 'password';
where:GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcf_sm.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcf_am.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcf_user.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_config_server.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_audit_service.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_release.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcrf_core.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_binding.* TO 'username'@'%'; FLUSH PRIVILEGES;
username is the username and password is the password for MYSQL admin user.
For Example: In the below example "occnpadminusr" is used as username, "occnpadminpasswd" is used as password and granting all the permissions to "occnpadminusr". In this example, default database names of micro services are used.CREATE USER 'occnpadminusr'@'%' IDENTIFIED BY 'occnpadminpasswd';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcf_sm.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcf_am.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcf_user.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_config_server.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_audit_service.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_release.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_pcrf_core.* TO 'occnpadminusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX ON occnp_binding.* TO 'occnpadminusr'@'%'; FLUSH PRIVILEGES;
- Create an application user and grant all the necessary permissions to the user
by executing the following command:
CREATE USER 'username'@'%' IDENTIFIED BY 'password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON occnp_pcf_sm.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_pcf_am.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON occnp_pcf_user.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_config_server.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_audit_service.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_pcrf_core.* TO 'username'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_binding.* TO 'username'@'%';
where:
username is the username and password is the password for MYSQL database user.
For Example: In the below example "occnpusr" is used as username, "occnppasswd" is used as password and granting the necessary permissions to "occnpusr". In this example, default database names of micro services are used.CREATE USER 'occnpusr'@'%' IDENTIFIED BY 'occnppasswd';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON occnp_pcf_sm.* TO 'occnpusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_pcf_am.* TO 'occnpusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON occnp_pcf_user.* TO 'occnpusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_config_server.* TO 'occnpusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_audit_service.* TO 'occnpusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_pcrf_core.* TO 'occnpusr'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON occnp_binding.* TO 'occnpusr'@'%';
Note:
The database name is specified in the envMysqlDatabase parameter for respective services in the custom-value.yaml file.It is recommended to use unique database name when there are multiple instances of Cloud Native Core Policy (CNC Policy) deployed in the network as they share the same data tier (MySQL cluster).
- Execute the command,
show grants for username
, to confirm that admin or application user has all the permissions.where, username is the admin or application user's username.
For Example,
show grants for occnpadminusr;
show grants for occnpusr;
- Exit from database and logout from MYSQL node.
- Create namespace if already does not exists by entering the command:
where:kubectl create namespace release_namespace
release_namespace is the deployment Cloud Native Core Policy (CNC Policy) namespace used by helm command.
For Example: In the below example "occnp" is used as namespace:kubectl create namespace occnp
- Create a kubernetes secret for an admin user and an application user
that were created in the step 5 and step 6.
To create a kubernetes secret for storing database username and password for these users:
- Create a yaml file with the application user's username
and password with the syntax shown below:
apiVersion: v1 kind: Secret metadata: name: occnp-db-pass type: Opaque data: mysql-username: b2NjbnB1c3I= mysql-password: b2NjbnBwYXNzd2Q=
- Create a yaml file with the admin user's username and
password with the syntax shown below:
apiVersion: v1 kind: Secret metadata: name: occnp-admin-db-pass type: Opaque data: mysql-username: b2NjbnBhZG1pbnVzcg== mysql-password: b2NjbnBhZG1pbnBhc3N3ZA==
Note:
'name' will be used for the dbCredSecretName and privilegedDbCredSecretName parameters in the CNC Policy custom-values.yaml file.Note:
The values for mysql-username and mysql-password should be base64 encoded. - Execute the following commands to add the kubernetes secrets in a namespace:
where:kubectl create -f yaml_file_name1 -n release_namespace kubectl create -f yaml_file_name2 -n release_namespace
release_namespace is the deployment namespace used by the helm command.
yaml_file_name1 is the name of the yaml file that is created in step a.
yaml_file_name2 is the name of the yaml file that is created in step b.
For example: In the below example "application.yaml" is used as yaml file name created in step a, "admin.yaml" is used as a filname created in step b, and "occnp" is used as a namespace created in step 9:kubectl create -f application.yaml -n occnp
kubectl create -f admin.yaml -n occnp
- Create a yaml file with the application user's username
and password with the syntax shown below:
Installing CNC Policy Package
To install the Cloud Native Core Policy (CNC Policy) package:
- Modify the required custom-values.yaml file with the
required input parameters. To customize the file, see Customizing Cloud Native Core Policy.
Note:
The values of the parameters mentioned in the custom values yaml file overrides the defaults values specified in the helm chart. If the envMysqlDatabase parameter is modified, then you should modify the configDbName parameter with the same value.Note:
perf-info has to be provided proper URL or else it will keep on restarting. [Below is an example of URL for bastion server]:perf-info:
configmapPerformance:
prometheus: http://occne-prometheus-server.occne-infra.svc
jaeger=jaeger-agent.occne-infra
-
Caution:
Do not exit fromhelm install
command manually. After running thehelm install
command, it takes some time to install all the services. In the meantime, you must not press "ctrl+c" to come out fromhelm install
command. It leads to some anomalous behavior.
where:helm install -f <custom_file> <release_name> <helm-chart> --namespace <release_namespace> --atomic --timeout 10m
helm_chart is the location of the helm chart extracted from occnp-pkg-1.8.1.tgz file
release_name is the release name used by helm command.Note:
release_name should not exceed 63 character limit.release_namespace is the deployment namespace used by helm command.
custom_file is the name of the custom values yaml file (including location).
For example:Parameters inhelm install -f occnp-1.8.0-custom-values-occnp.yaml occnp /home/cloud-user/occnp-1.8.0.tgz --namespace occnp --atomic
helm install
command:- atomic: If this parameter is set, installation process purges chart on failure. The --wait flag will be set automatically.
- wait: If this parameter is set, installation process will wait until all pods, PVCs, Services, and minimum number of pods of a deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout.
- timeout duration (optional): If not specified,
default value will be 300 (300 seconds) in Helm2 and 5m (5 minutes) in
Helm3. It 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.
- You can verify the installation while running the install command by entering
this
command:
Press "Ctrl+C" to exit watch mode. We should run thewatch kubectl get jobs,pods -n release_namespace
watch
command on another terminal.helm status release_name -n release_namespace
- Check the installation status by entering this
command:
For example:helm ls release_name
You will see the status as DEPLOYED if the deployment is done successfully.helm ls occnp
Execute the following command to get status of jobs and pods:For example:kubectl get jobs,pods -n release_namespace
You will see the status as Running for all the pods if the deployment is done successfully.kubectl get pod -n occnp
Execute the following command to get status of services:For example:kubectl get services -n release_namespace
kubectl get services -n occnp
Note:
If the installation is not successful or you do not see the status as Running for all the pods, perform the troubleshooting steps given under Troubleshooting Cloud Native Core Policy (CNC Policy).