Add Customization Option for Controller Name

[andpozo]

Is your feature request related to a problem?

Yes, the lack of customization for the controller name makes it impossible to deploy multiple instances of the AWS Load Balancer Controller within the same Kubernetes cluster. This limitation is problematic for setups requiring separate public and private ingress controllers, especially in compliance-driven architectures such as those mandated by SOC2 and ISO27001.

Describe the solution you'd like

I'm using the AWS Load Balancer Controller in a setup where I need to register two instances of the controller: one for public ingress and one for private ingress. This setup aligns with the requirements outlined in the AWS whitepaper for building scalable and secure multi-VPC network infrastructure (link), particularly for SOC2 and ISO27001 compliance.

Currently, the controller name is hardcoded in the pkg/ingress/class_loader.go file (link to line).

I propose adding an extra configuration option to the pkg/config/ingress_config.go file (link) that allows users to customize the controller name.

This change would enable users to:

• Register multiple instances of the AWS Load Balancer Controller.
• Differentiate between public and private ingress configurations.

Benefits

• Provides flexibility for advanced ingress setups.
• Supports compliance with SOC2 and ISO27001 by enabling centralized ingress management.

Suggested Implementation

Add a new field (e.g., controllerName) to the IngressConfig struct in pkg/config/ingress_config.go.
Modify the hardcoded controller name in pkg/ingress/class_loader.go to use the configurable value from IngressConfig.
Update the default behavior to maintain backward compatibility (e.g., default to the existing hardcoded name if the new option is not specified).

Architecture Diagram

Below is an architectural diagram that illustrates the proposed setup with two Load Balancer Controllers, one managing public ingress and another managing private ingress. This setup ensures compliance with centralized ingress requirements for secure multi-VPC environments:

Describe alternatives you've considered

A description of any alternative solutions or features you've considered.

[andpozo]

I have successfully deployed separate public and private ingress controllers in different Kubernetes clusters, and they worked as expected. However, when attempting to deploy both controllers within the same Kubernetes instance, I encountered conflicts due to the hardcoded controller name. These conflicts make it impossible to run both controllers simultaneously, which is a requirement for my centralized ingress setup.

Allowing customization of the controller name would resolve this issue and enable seamless operation of multiple ingress controllers within the same Kubernetes cluster, supporting both public and private ingress scenarios.

[andpozo]

In addition, I propose updates to the Helm chart to make this feature easily configurable for users:

• Add a customizable value (e.g., controllerName) in the values.yaml file.
• Update the ingressclass.yaml template (link) to use this value dynamically when defining the ingress class.
• Include the same customizable value as an extra parameter in the deployment.yaml template (link) to propagate the configuration to the controller pod.

This would allow users to easily set distinct controller names for different deployments directly via the Helm chart, simplifying multi-controller setups without requiring additional manual configuration.