The new Load Balancer (LB) feature for the NextGen Gateway improves traffic management and service availability by consolidating services under a single external IP. This feature can be deployed in two ways:

• Enabling the new Load Balancer on a fresh setup
• Migrating an existing deployment to use the Load Balancer

Enabling the New Load Balancer

To enable the Single Load Balancer (LB) Controller feature, use the provided helper script that automates all necessary configuration changes.

Using the Helper Script

1. Contact OpsRamp Support to obtain the enable-single-lb-controller.sh script.
2. Place the script on the NextGen Gateway server.
3. Make the script executable:

   chmod +x enable-single-lb-controller.sh 

4. Run the script with your desired action:

   ./enable-single-lb-controller.sh [ACTION] [NAMESPACE] [REPOSITORY_OPTION]

Available Actions:

Examples:

# Enable the feature in the default namespace
./enable-single-lb-controller.sh enable default

# Disable the feature in the monitoring namespace
./enable-single-lb-controller.sh disable monitoring

# Mark agent migration as complete in the default namespace
./enable-single-lb-controller.sh opsramp-agent-migrated default

# Enable using an alternative chart repository
./enable-single-lb-controller.sh enable default repo=harbor-docker.pkg.dev

Migration Steps for Existing Deployments

When upgrading existing Gateway deployments to use the new Load Balancer feature, follow these steps:

1. Enable the Single LB Controller:

   ./enable-single-lb-controller.sh enable <NAMESPACE> 

2. Update your agents to point to the new Squid proxy service.
   • During migration, both old and new Squid proxy services will be available temporarily.
   • Gradually update your agents to use the new service.
3. After all agents have been updated, mark the migration as complete:

   ./enable-single-lb-controller.sh opsramp-agent-migrated <NAMESPACE>

   Note

   1. If the Migration Completed, flag is enabled:
      The original squid-proxy service using the old IP (if it exists) will be discontinued and no longer accessible.
   2. If the Migration Completed, flag is not enabled:
      The original squid-proxy service will continue to operate using the old IP as usual.
4. Future upgrades will no longer use the original Squid proxy service.

   Tip

   The dual-service transition ensures continuous agent operation during migration.

Verifying the Configuration

After enabling the Load Balancer feature, verify that it is working as expected:

1. Verify if the Load Balancer controller pod is running.

   kubectl get pods -n <NAMESPACE> | grep lb-controller

2. List all services and confirm the consolidated external IP.

   kubectl get svc -n <NAMESPACE>

You should see the LB Controller pod running and services using a single external IP.

Disable the Load Balancer

If you want to disable the Load Balancer and revert to the previous configuration, run:

./enable-single-lb-controller.sh disable <NAMESPACE>

This will disable the Single LB Controller feature and restore the original setup.

Advanced Auto-Scaling Configuration

Modify scaling parameters in values.yaml for optimal scaling:

squid:
  hpa:
    minReplicas: 1  # Minimum instances
    maxReplicas: 5  # Maximum instances
    metrics:
      memory:
        averageUtilization: 80  # Trigger scaling at 80% memory usage

Troubleshooting

If issues arise, follow these steps:

1. Check Load Balancer Logs:

   kubectl logs -f nextgen-gw-lb-controller-[hash] -n <namespace>

2. View Load Balancer Controller Pod Details:

   kubectl describe pod nextgen-gw-lb-controller-[hash] -n <namespace>

3. Verify MetalLB Status:

   kubectl get pods -n kube-system

4. Check Squid Proxy Services:

   kubectl get pods -n <namespace> | grep squid

   kubectl get svc -n <namespace> | grep squid