Kubernetes Tutorials: IngressGroup on EKS (ALB Ingress): A Practical Guide to One-ALB-for-Many-Namespaces

What is an IngressGroup (and why it matters)

IngressGroup lets you share a single ALB across multiple Ingress objects (even across different namespaces). The controller merges all rules from Ingresses with the same alb.ingress.kubernetes.io/group.name onto one ALB; you can also control rule priority with alb.ingress.kubernetes.io/group.order. This reduces cost and operational sprawl while keeping teams free to manage their own Ingress manifests. (AWS Documentation)

Key behaviors

• Share one ALB across many Ingresses (and namespaces) via group.name. (AWS Documentation)
• Rule evaluation order across the group is governed by group.order (lower numbers evaluated first; 1–1000). Unset = 0. Each Ingress in a group must have a unique order if you set it. (Amazon Web Services, Inc.)
• Most annotations apply only to the paths on that Ingress, not globally to the ALB. (AWS Documentation)
• Trust boundary warning: anyone who can create/modify an Ingress with the same group.name can add/override rules on “your” ALB—use only within a trusted RBAC boundary. (kubernetes-sigs.github.io)

When to use IngressGroup

Use it when you want to:

• Reduce ALB count/cost by hosting many apps, microservices, or environments on one ALB. (Amazon Web Services, Inc.)
• Decentralize ownership: each team owns its own Ingress, but traffic still lands on a single ALB (great for platform teams). (Amazon Web Services, Inc.)
• Route by host/path across namespaces: e.g., api.example.com/vehicle → apps/vehicle, ops.example.com/metrics → ops/metrics. (Medium)
• Control match precedence (e.g., wildcard catch-alls after specific paths) with group.order. (Amazon Web Services, Inc.)

When not to use IngressGroup

Avoid it if:

• Multi-tenant untrusted RBAC: tenants could hijack or shadow rules on the shared ALB. (Trust boundary caveat.) (kubernetes-sigs.github.io)
• Divergent ALB settings are required per app (e.g., different schemes internet-facing vs internal, incompatible listener ports, incompatible target types). A group shares one ALB’s global properties. (AWS Documentation)
• Distinct security/waf/ops policies must apply per app at the edge (separate WAF ACLs, SGs, or lifecycle). Keep separate ALBs then. (Amazon Web Services, Inc.)
• You need fine-grained priority beyond group.order but can’t coordinate unique orders; duplicates aren’t allowed. (AWS Documentation)

Reference design: single ALB, multiple namespaces

1) Shared ALB “edge” Ingress (optional)

You can start with no “edge” ingress—the controller will still merge ALB rules. If you prefer a named ALB and shared listeners, create a tiny “anchor” Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shared-alb
  namespace: platform
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/load-balancer-name: prod-shared-alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/group.name: prod-ing
    alb.ingress.kubernetes.io/group.order: "1"
spec:
  tls:
    - hosts: [ "api.example.com", "ops.example.com" ]
      secretName: wildcard-example-tls
Code language: JavaScript (javascript)

Notes: One ALB will be created with the name above and HTTPS 443 listener. Additional Ingresses in other namespaces join the same group and add rules to this ALB. (AWS Documentation)

2) App team A (namespace apps): host+path routing

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vehicle-ing
  namespace: apps
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/group.name: prod-ing
    alb.ingress.kubernetes.io/group.order: "10"   # evaluated after “1”
    alb.ingress.kubernetes.io/healthcheck-path: /healthz
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /vehicle
        pathType: Prefix
        backend:
          service:
            name: vehicle
            port:
              number: 8080
      - path: /legal
        pathType: Prefix
        backend:
          service:
            name: legal
            port:
              number: 8080

3) App team B (namespace ops): separate host

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ops-ing
  namespace: ops
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/group.name: prod-ing
    alb.ingress.kubernetes.io/group.order: "20"
spec:
  rules:
  - host: ops.example.com
    http:
      paths:
      - path: /metrics
        pathType: Prefix
        backend:
          service:
            name: metrics
            port:
              number: 9090
      - path: /dash
        pathType: Prefix
        backend:
          service:
            name: grafana
            port:
              number: 3000

What happens: the controller merges these Ingresses (different namespaces) under one ALB, installing rules in priority order (1, then 10, then 20). Lower order wins on conflicts and is evaluated first. (Amazon Web Services, Inc.)

Rule ordering & conflicts (gotchas)

• Lower group.order = evaluated first. Default (unset) is 0. Give each Ingress in a group a unique order to avoid surprises. (Amazon Web Services, Inc.)
• If two Ingresses define overlapping matches, the one with a lower order takes precedence. Wildcards (like /*) should have higher order so they’re evaluated later. (about.gitlab.com)
• If you don’t set group.order, the controller falls back to lexical namespace/name ordering—usually not what you want in prod. Set it explicitly. (Amazon Web Services, Inc.)

Cross-namespace & per-ingress annotations

• Cross-namespace sharing is fully supported; keep each Ingress with the Service it fronts for clarity. (Medium)
• Most annotations (timeouts, health checks, stickiness, etc.) apply only to the paths on that Ingress, not the entire ALB. This is why different teams can tune behavior for their own routes while sharing the ALB. (AWS Documentation)

Operational best practices

1. Define the trust boundary
   Restrict who can set group.name to your shared value; treat it like a shared infrastructure resource. Consider admission controls or a centralized Helm chart to prevent accidental conflicts. (kubernetes-sigs.github.io)
2. Pin global ALB attributes once
   Listener ports (listen-ports), scheme, target-type, and base SSL policy should be aligned across the group. Keep a tiny “anchor” Ingress to standardize them. (AWS Documentation)
3. Always set group.order
   Make a simple policy (e.g., 1 for anchor, 10–99 for app teams, 900+ for catch-alls). Document it. (Amazon Web Services, Inc.)
4. Certificates & hostnames
   Use an ACM certificate covering all hosts (SANs or wildcard). If you terminate TLS on the ALB, put the cert on the shared ALB and keep TLS secrets consistent. (AWS Documentation)
5. Health checks per path
   Each Ingress can set its own alb.ingress.kubernetes.io/healthcheck-* on its paths—great for heterogeneous backends. (AWS Documentation)
6. ExternalDNS (optional)
   Multiple hostnames can map to the same ALB. Use ExternalDNS records (CNAME/Alias) for each host. (Pattern often seen in multi-namespace single-ALB setups.) (Stack Overflow)
7. Listener ports
   Ensure at least one Ingress (often the anchor) declares listen-ports for predictable listeners; some users hit quirks without it. (GitHub)

Migration recipe (from many ALBs → one ALB)

1. Pick a group name (e.g., prod-ing) and create the anchor Ingress with desired scheme/listeners/target-type. (AWS Documentation)
2. Update each app’s Ingress: add group.name: prod-ing and a unique group.order.
3. Validate merged rules in the ALB console (hosts, paths, priorities).
4. Flip DNS (if needed) to the shared ALB; remove old per-app ALBs.

Quick test plan

• curl -I https://api.example.com/vehicle/healthz → expect 200 from apps/vehicle.
• curl -I https://ops.example.com/metrics/ → expect 200 from ops/metrics.
• Temporarily add a catch-all Ingress with higher order (900) and confirm it doesn’t shadow specific rules.

FAQ

Q: Can different namespaces use different health checks, timeouts, or stickiness?
A: Yes—set those annotations on each Ingress; they apply to that Ingress’s paths only. (AWS Documentation)

Q: Can I mix internet-facing and internal in the same group?
A: No. Those are ALB-level attributes; split into separate groups/ALBs. (AWS Documentation)

Q: Who wins if two teams define the same host+path?
A: The Ingress with the lower group.order wins (evaluated first). Coordinate orders to avoid accidental overrides. (Amazon Web Services, Inc.)

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.