...
maximum-pool-size: 20
**The following change on the example above has been tested and passes all CSIT tests and is deployable.
Load Balancing Options
Load balancing option | Description | Issues | Possible solution |
---|
Increasing pod/replica count via deployment object - This method has been tested on minikube to create 3 instances of cps-ncmp
- Each pod were monitored through logs
- one specific pod accomodated majority of the requests
- one pod did not accept requests at all
- as client, received correct responses
| Replica count is changed from the default number to the number of pods desired to be added through values.yaml file - Defined in the manifest deployment.yaml which means the deployment object created will own and manage the replicaSet
- this is the recommended way to use replicaSets
| - Burst propagation
- eviction of one replica results in the load being redirected to another replica
- CPU in the node can be/will be fully used up
| - adding a Horizontal Pod Autoscaler (HPA)
|
Database Bottleneck | ****can be a different study on how to scale Postgres horizontally - Vertical Scaling
- more resources such as CPU and memory are added
- Postgres horizontal scaling (Sharding)
- Slices tables into multiple smaller tables (shards) wherein each will be in run on different database
- ***Feedback from Renu Kumari
- Based on the reasons below, Bell decided not to work on scaling the database at the moment:
- Postgres charts used by CPS uses 'deployments' instead of 'stateful' sets
- Complex task
- Changing the current Postgres charts will impact other components
- ONAP also have an initiative to separate services from the storage.
|
Using Horizontal Pod Autoscaling | - allows the automatic deployment of pods to satisfy the stated configuration wherein the number of pods depends on the load
- i.e. the workload resource will be scaled back down if the load decreases and the number of pods are above the configured minimum.
- HPA can be defined with multiple and custom metrics.
- metrics can be customized so that HPA only scales on HTTP requests
- metrics can be customized so that HPA only scales on Ingress requests per second
Gliffy Diagram |
---|
size | 300 |
---|
displayName | Diagram 3 |
---|
name | Diagram 3 |
---|
pagePin | 6 |
---|
|
| - HPA scales up and distributes workload efficiently over the replicas with the linearly increasing workload but takes time to scale up or down with bursty workloads
| - Configure sync period
- the default interval is 15 seconds
|
- Would require changes/updates to the current CPS deployment resources
| - Remove 'replica' variable in cps-and-ncmp deployment manifest
- deployment.yaml
- apiVersion: apps/v1
kind: Deployment metadata: {{- include "common.resourceMetadata" . | nindent 2 }} spec: replicas: {{ .Values.replicaCount }}
- . . .
- Add a manifest to create a HorizontalPodAutoscaler object
- sample HPA manifest
- apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler metadata: name: cps-and-ncmp spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: cps-and-ncmp minReplicas: 1 maxReplicas: 10 metrics:
- type: Object object: metric: name: requests-per-second describedObject: apiVersion: networking.k8s.io/v1beta1 kind: Ingress name: cps-core-ingress target: type: Value value: 100 .... - Might need to add a separate service to support monitoring metrics
- service needs to implement custom.metrics.k8s.io or external.metrics.k8s.io
|
...