AWS ALB tagging issue during the Sisense installation [Linux]

Introduction

While deploying Sisense on EKS with ALB  (https://docs.sisense.com/main/SisenseLinux/using-an-aws-load-balancer-controller-with-sisense-on-amazon-eks.htm), you may notice that the installation has passed smoothly, but a load balancer is missing in the AWS console.  Usually, it happens when a cluster doesn’t create new subnets but uses existing ones (e.g., this case: https://community.sisense.com/kb/cloud_managed_service/creating-and-deleting-eks-cluster-in-the-existing-vpc/26443). (On-prem)

Step-by-Step Guide

1. Check if the AWS Load Balancer Controller pods are up and running. They should be in the default namespace unless you’ve changed the default utils-namespace installer option to another value. 

 kubectl -n default get pods

2. If they are up and running, please check the logs:

kubectl -n default logs -l app.kubernetes.io/name=aws-load-balancer-controller

You may see the following output: 

{"level":"error","ts":1758602590.9472752,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"}

{"level":"error","ts":1758603591.1477435,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"}

{"level":"error","ts":1758604591.3403745,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"}

{"level":"error","ts":1758605591.5673392,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"}

The aws-load-balancer-controller relies on specific tags on your subnets to auto-discover them. If these tags are missing, the controller cannot find a suitable subnet to provision the ALB, leading to the "couldn't auto-discover subnets" error. This is a common issue, especially if the VPC and subnets were created manually or by a different process that didn't include the required tags.

3. To resolve this, you must manually tag the public and private subnets in your VPC. The tags must follow a specific format.

4. You also need to tag your subnets with such a tag if they are used by this cluster only 

kubernetes.io/cluster/YOUR-CLUSTER-NAME: owned

Or, if these subnets are also being used by other services, use ‘shared’ value instead:

kubernetes.io/cluster/YOUR-CLUSTER-NAME: shared

The your-cluster-name part should be replaced with the actual name of your EKS cluster. The value owned tells the controller that it has ownership of the resource and can modify it.

5. After adding the tags, the aws-load-balancer-controller will automatically detect the changes. It will reconcile the Ingress resource and provision the ALB. This process may take a few minutes. Check the controller logs again (kubectl -n default logs -l app.kubernetes.io/name=aws-load-balancer-controller -f) for a “Successfully provisioned load balancer”  message.

Conclusion

A missing ALB after an EKS deployment on the existing subnets is often caused by a subnet tagging issue. The aws-load-balancer-controller requires specific tags to auto-discover and use them. By manually adding these tags to your VPC subnets, you can quickly resolve the "couldn't auto-discover subnets" error and allow the controller to successfully provision your Application Load Balancer.

References/Related Content 

• https://docs.sisense.com/main/SisenseLinux/using-an-aws-load-balancer-controller-with-sisense-on-amazon-eks.htm
• https://community.sisense.com/kb/cloud_managed_service/creating-and-deleting-eks-cluster-in-the-existing-vpc/26443
• https://repost.aws/knowledge-center/eks-vpc-subnet-discovery

Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.