Managing Network Bridge Pods

7 Managing Network Bridge Pods

You can manage the pods in your Oracle Communications Network Bridge cloud native deployment by setting up autoscaling.

Topics in this document:

Setting up Autoscaling of Network Bridge Pods

Setting up Autoscaling of Network Bridge Pods

You can use the Kubernetes Horizontal Pod Autoscaler to automatically scale up or scale down the number of pod replicas based on a pod's CPU or memory utilization. In Network Bridge cloud native deployments, the Horizontal Pod Autoscaler can monitor and scale these pods:

mediation
egress
diameter-adapter-h2d
diameter-adapter-d2h
diameter-proxy

Changing the number of replicas in a Network Bridge autoscalable ReplicaSet rebalances the in-memory cache distribution across the replicas. This rebalancing activity consumes incremental CPU and memory resources and can take multiple seconds to complete. Therefore, your autoscaling design should strike a balance between optimizing infrastructure resource usage and minimizing changes to the number of replicas in a ReplicaSet due to autoscaling.

To set up and enable autoscaling for Network Bridge pods:

Ensure that your Network Bridge cluster is set up and the system is in the UsageProcessing state.
Open your override-values.yaml file.
Enable the Horizontal Pod Autoscaler in all of the pods by setting these keys to true:
- For the mediation pod: network-bridge.mediation.mediation.hpa.enabled
- For the mediation pod in a REST proxy: network-bridge-restproxy.rest-proxy.mediation.hpa.enabled
- For the egress pod: network-bridge.egress.mediation.hpa.enabled
- For the diameter-adapter-h2d pod: network-bridge.diameter-adapter-h2d.protocolTransform.hpa.enabled
- For the diameter-adapter-d2h pod: network-bridge.diameter-adapter-d2h.protocolTransform.hpa.enabled
- For the diameter-proxy pod: network-bridge.diameter-proxy.diameterProxy.hpaEnabled
For each pod, specify the minimum and maximum amount of memory and CPU that can be used.

Set these keys under the resources section of each pod. For example, under diameter-adapter-h2d.protocolTransform.resources.
- memoryRequest: Set this to the minimum amount of memory required for a Kubernetes node to deploy a pod.
  
  If the minimum amount is not available, the pod's status is set to Pending.
- cpuRequest: Set this to the minimum CPU amount, in millicores, that must be available in a Kubernetes node to deploy a pod. For example, enter 1000m for 1 CPU core.
  
  If the minimum CPU amount is not available, the pod's status is set to Pending.
- memoryLimit: Set this to the maximum amount of memory that a pod can utilize.
- cpuLimit: Set this to the maximum amount of CPU that a pod can utilize.
For each pod, specify the minimum and maximum number of pod replicas that can be deployed.

Set these keys under the hpa section of each pod. For example, under the network-bridge.egress.mediation.hpa section.
- minReplicas: Set this to the minimum number of pod replicas to deploy when scale down is triggered.
  
  If a pod's average utilization goes below cpuAverageUtilization, the Horizontal pod Autoscaler decreases the number of pod replicas down to this minimum count.
- maxReplicas: Set this to the maximum number of pod replicas to deploy when scale up is triggered.
  
  If a pod's average utilization goes above cpuAverageUtilization, the Horizontal pod Autoscaler increases the number of pod replicas up to this maximum count.
- metrics.cpuAverageUtilization: Set this as a target or threshold for average CPU usage across all of the pod's replicas with the same entry point. For example, if a cluster has three mediation pod replicas, the average will be the sum of CPU usage divided by three. The default is 65%.
  
  The autoscaler increases or decreases the number of pod replicas to maintain the average CPU utilization you specified across all pods.
For each pod, specify the rules for scaling down pods.

Set these keys under the hpa.scaleDown section of each pod. For example, under the network-bridge.egress.mediation.hpa.scaleDown section.
- selectPolicy: Specifies Min, Max, or Disabled.
  - Min selects the policy with the smallest change in the replica count.
  - Max selects the policy with the largest change in the replica count.
  - Disabled prevents autoscaling in the scale down direction.
- stabilizationWindowSeconds: Specifies the duration, in seconds, of the stabilization window when scaling down pods.
- periodSeconds: Specifies the number of seconds for which metrics should be collected before scaling.
For each pod, specify the rules for scaling up pods.

Set these keys under the hpa.scaleUp section of each pod. For example, under the network-bridge.egress.mediation.hpa.scaleUp section.
- selectPolicy: Specifies Min, Max, or Disabled.
  - Min selects the policy with the smallest change in the replica count.
  - Max selects the policy with the largest change in the replica count.
  - Disabled prevents autoscaling in the scale down direction.
- stabilizationWindowSeconds: Specifies the duration, in seconds, of the stabilization window when scaling up pods.
- periodSeconds: Specifies the number of seconds for which metrics should be collected before scaling.
To lower the heap memory used by the pods, set the appropriate JVM parameters in the jvmOpts key.

Memory-based scale down occurs only if the amount of pod memory decreases. You can decrease pod memory by using JVM garbage collection (GC).
Save and close your override-values.yaml file.
Do one of the following:
- Deploy Network Bridge (if you have not already deployed Network Bridge). See "Deploying Network Bridge".
- If you have already deployed Network Bridge, update your Network Bridge release:
```
helm upgrade NBReleaseName oc-ccs-helm-chart-version --values override-values.yaml -n NBNameSpace
```
  where:
  - NBReleaseName is the release name for the Network Bridge deployment.
  - version is the Network Bridge release number, such as 2.0.0.
  - NBNameSpace is the namespace in which to create Kubernetes objects for the Network Bridge Helm chart.