Skip to content

fix(troubleshooting): alb not showing up - #1924

Open
arcegacardenas wants to merge 1 commit into
aws-samples:mainfrom
arcegacardenas:fix/troubleshooting-alb-inbound-cidrs
Open

arcegacardenas wants to merge 1 commit into
aws-samples:mainfrom
arcegacardenas:fix/troubleshooting-alb-inbound-cidrs

Conversation

@arcegacardenas

Copy link
Copy Markdown
Contributor

…ress

The troubleshooting/alb setup applied the ui ingress via a plain 'kubectl apply -k', so the 'alb.ingress.kubernetes.io/inbound-cidrs: $INBOUND_CIDRS' annotation was stored as a literal string. The AWS Load Balancer Controller then failed model-building on every reconcile with 'invalid CIDR address: $INBOUND_CIDRS', so the ALB was never created -- masking the intended subnet-tag (alb_fix_1) and IAM (alb_fix_5) scenarios and leaving alb_fix_5 Step 4 unable to show an ALB hostname.

Apply the ingress through envsubst using the module's inbound_cidrs variable (mirroring how alb_fix_7 applies fix_ingress) so a valid CIDR is baked in at setup. The backend service-ui / ui-app selector issues are left untouched for alb_fix_7.

Verified on a local deployment: after prepare-environment the annotation holds a real CIDR, the documented subnet/IAM errors surface as intended, and alb_fix_5 Step 4 returns an ALB hostname.

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Quality checks

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

…ress

The troubleshooting/alb setup applied the ui ingress via a plain
'kubectl apply -k', so the 'alb.ingress.kubernetes.io/inbound-cidrs:
$INBOUND_CIDRS' annotation was stored as a literal string. The AWS Load
Balancer Controller then failed model-building on every reconcile with
'invalid CIDR address: $INBOUND_CIDRS', so the ALB was never created --
masking the intended subnet-tag (alb_fix_1) and IAM (alb_fix_5) scenarios
and leaving alb_fix_5 Step 4 unable to show an ALB hostname.

Apply the ingress through envsubst using the module's inbound_cidrs
variable (mirroring how alb_fix_7 applies fix_ingress) so a valid CIDR is
baked in at setup. The backend service-ui / ui-app selector issues are
left untouched for alb_fix_7.

Verified on a local deployment: after prepare-environment the annotation
holds a real CIDR, the documented subnet/IAM errors surface as intended,
and alb_fix_5 Step 4 returns an ALB hostname.
@netlify

netlify Bot commented Sep 4, 2026

Copy link
Copy Markdown

Deploy Preview for eks-workshop ready!

Name Link
🔨 Latest commit ce7f491
🔍 Latest deploy log https://app.netlify.com/projects/eks-workshop/deploys/6a9b05fb10fa3700081fb229
😎 Deploy Preview https://deploy-preview-1924--eks-workshop.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@robisoh88

Copy link
Copy Markdown
Contributor

Hit this same issue.

I applied the documented alb_fix_1 subnet remediation on top of the broken state: subnet-discovery errors dropped to 0, but CIDR rejections continued (14 more) and the Ingress ADDRESS stayed empty.

Also breaks CI: alb_fix_5 declares hookTimeout=600 and its hook polls .status.loadBalancer.ingress[*].hostname, which never populates while the Ingress is unreconcilable — so the hook burns the full 600s and fails.

Scoping envsubst '$INBOUND_CIDRS' to the one variable is a nice touch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants