NRF Client

NRF Client updates an external NRF on the availability of an NF service. This mirrors the default behavior of SBA Gateway. NRF Client uses the Kubernetes API to find the running pods of the NF service and queries their metrics to discover the current CPU capacity and CPU load. The total CPU capacity and average CPU load are then reported back to the NRF by updating the nfProfile it holds for the service.

Figure 1 shows the connections between NRF Client and other components.

Figure 1. NRF Client Connections

NRF Client connects to an NRF using either an active-active or active-standby strategy. NRF Client Connection Strategies describes each strategy.

Table 1. NRF Client Connection Strategies
Connection Strategy Description
Active-Active NRF Client registers with and sends heartbeats to each NRF specified in nrf.clients. When an NRF is not available, NRF Client continues to attempt to send a heartbeat to it.
Active-Standby NRF Client expects to connect to only one NRF. The first NRF specified in nrf.clients is considered to be primary. If NRF Client fails to connect to this primary NRF, then the next in the list is attempted. If nrf.activeStandbyReturnToPrimary is set to true (default), then if the primary NRF becomes available again and NRF Client unregisters from the current NRF and reconnects to the primary.

NRF Client is deployed using the MATRIXX common Helm chart. NRF Client itself is service-agnostic and can be customized for each service type it is monitoring, such as CHF Diameter Adapter or CHF Proxy. Each service type has a set of values that must be updated with deployment-specific information. For example, for CHF Proxy, you must specify the NRF Clients and the service address (in the nfProfile) in the Helm values file.

Important: NRF Client must be deployed to the same namespace as the NF services it is monitoring.