IngressGroup<\/strong> lets you share a single ALB<\/strong> across multiple Ingress objects<\/strong> (even across different namespaces). The controller merges all rules<\/strong> from Ingresses with the same Key behaviors<\/strong><\/p>\n\n\n\n Use it when you want to:<\/p>\n\n\n\n Avoid it if:<\/p>\n\n\n\n You can start with no \u201cedge\u201d ingress<\/strong>\u2014the controller will still merge ALB rules. If you prefer a named ALB and shared listeners, create a tiny \u201canchor\u201d Ingress:<\/p>\n\n\n Notes: One ALB<\/strong> will be created with the name above and HTTPS 443<\/strong> listener. Additional Ingresses in other namespaces join the same group<\/strong> and add rules to this ALB. (AWS Documentation<\/a>)<\/p>\n<\/blockquote>\n\n\n\n What happens:<\/strong> the controller merges<\/strong> these Ingresses (different namespaces) under one ALB<\/strong>, installing rules in priority order<\/strong> ( Q: Can different namespaces use different health checks, timeouts, or stickiness?<\/strong> Q: Can I mix alb.ingress.kubernetes.io\/group.name<\/code> onto one ALB<\/strong>; you can also control rule priority<\/strong> with alb.ingress.kubernetes.io\/group.order<\/code>. This reduces cost and operational sprawl while keeping teams free to manage their own Ingress manifests. (AWS Documentation<\/a>)<\/p>\n\n\n\n\n
group.name<\/code>. (AWS Documentation<\/a>)<\/li>\n\n\n\ngroup.order<\/code> (lower numbers evaluated first; 1\u20131000). Unset = 0<\/code>. Each Ingress in a group must have a unique<\/strong> order if you set it. (Amazon Web Services, Inc.<\/a>)<\/li>\n\n\n\ngroup.name<\/code> can add\/override rules on \u201cyour\u201d ALB\u2014use only within a trusted RBAC boundary<\/strong>. (kubernetes-sigs.github.io<\/a>)<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nWhen to use IngressGroup<\/h2>\n\n\n\n
\n
api.example.com\/vehicle<\/code> \u2192 apps\/vehicle<\/code>, ops.example.com\/metrics<\/code> \u2192 ops\/metrics<\/code>. (Medium<\/a>)<\/li>\n\n\n\ngroup.order<\/code>. (Amazon Web Services, Inc.<\/a>)<\/li>\n<\/ul>\n\n\n\nWhen not<\/em> to use IngressGroup<\/h2>\n\n\n\n
\n
internet-facing<\/code> vs internal<\/code>, incompatible listener ports<\/strong>, incompatible target types<\/strong>). A group shares one ALB\u2019s global properties. (AWS Documentation<\/a>)<\/li>\n\n\n\n
\n\n\n\nReference design: single ALB, multiple namespaces<\/h2>\n\n\n\n
1) Shared ALB \u201cedge\u201d Ingress (optional)<\/h3>\n\n\n\n
apiVersion: networking.k8s.io\/v1\nkind<\/span>: Ingress\nmetadata<\/span>:\n name: shared-alb\n namespace<\/span>: platform\n annotations<\/span>:\n kubernetes.io\/ingress.class: alb\n alb.ingress.kubernetes.io\/load-balancer-name: prod-shared-alb\n alb.ingress.kubernetes.io\/scheme: internet-facing\n alb.ingress.kubernetes.io\/target-type: ip\n alb.ingress.kubernetes.io\/listen-ports: '[{\"HTTPS\":443}]'<\/span>\n alb.ingress.kubernetes.io\/group.name: prod-ing\n alb.ingress.kubernetes.io\/group.order: \"1\"<\/span>\nspec<\/span>:\n tls:\n - hosts: [ \"api.example.com\"<\/span>, \"ops.example.com\"<\/span> ]\n secretName<\/span>: wildcard-example-tls\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n\n
2) App team A (namespace
apps<\/code>): host+path routing<\/h3>\n\n\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: vehicle-ing\n namespace: apps\n annotations:\n kubernetes.io\/ingress.class: alb\n alb.ingress.kubernetes.io\/group.name: prod-ing\n alb.ingress.kubernetes.io\/group.order: \"10\" # evaluated after \u201c1\u201d\n alb.ingress.kubernetes.io\/healthcheck-path: \/healthz\nspec:\n rules:\n - host: api.example.com\n http:\n paths:\n - path: \/vehicle\n pathType: Prefix\n backend:\n service:\n name: vehicle\n port:\n number: 8080\n - path: \/legal\n pathType: Prefix\n backend:\n service:\n name: legal\n port:\n number: 8080\n<\/code><\/span><\/pre>\n\n\n3) App team B (namespace
ops<\/code>): separate host<\/h3>\n\n\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: ops-ing\n namespace: ops\n annotations:\n kubernetes.io\/ingress.class: alb\n alb.ingress.kubernetes.io\/group.name: prod-ing\n alb.ingress.kubernetes.io\/group.order: \"20\"\nspec:\n rules:\n - host: ops.example.com\n http:\n paths:\n - path: \/metrics\n pathType: Prefix\n backend:\n service:\n name: metrics\n port:\n number: 9090\n - path: \/dash\n pathType: Prefix\n backend:\n service:\n name: grafana\n port:\n number: 3000\n<\/code><\/span><\/pre>\n\n\n1<\/code>, then 10<\/code>, then 20<\/code>). Lower order wins on conflicts and is evaluated first. (Amazon Web Services, Inc.<\/a>)<\/p>\n\n\n\n
\n\n\n\nRule ordering & conflicts (gotchas)<\/h2>\n\n\n\n
\n
group.order<\/code> = evaluated first<\/strong>. Default (unset) is 0<\/code>. Give each Ingress in a group a unique<\/strong> order to avoid surprises. (Amazon Web Services, Inc.<\/a>)<\/li>\n\n\n\n\/*<\/code>) should have higher<\/strong> order so they\u2019re evaluated later<\/strong>. (about.gitlab.com<\/a>)<\/li>\n\n\n\ngroup.order<\/code>, the controller falls back to lexical namespace\/name<\/strong> ordering\u2014usually not what you want in prod. Set it explicitly. (Amazon Web Services, Inc.<\/a>)<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nCross-namespace & per-ingress annotations<\/h2>\n\n\n\n
\n
\n\n\n\nOperational best practices<\/h2>\n\n\n\n
\n
Restrict who can set group.name<\/code> to your shared value; treat it like a shared infrastructure resource<\/strong>. Consider admission controls or a centralized Helm chart to prevent accidental conflicts. (kubernetes-sigs.github.io<\/a>)<\/li>\n\n\n\n
Listener ports (listen-ports<\/code>), scheme<\/code>, target-type<\/code>, and base SSL policy should be aligned across the group. Keep a tiny \u201canchor\u201d Ingress to standardize them. (AWS Documentation<\/a>)<\/li>\n\n\n\ngroup.order<\/code><\/strong>
Make a simple policy (e.g., 1<\/code> for anchor, 10\u201399<\/code> for app teams, 900+<\/code> for catch-alls). Document it. (Amazon Web Services, Inc.<\/a>)<\/li>\n\n\n\n
Use an ACM certificate<\/strong> 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<\/a>)<\/li>\n\n\n\n
Each Ingress can set its own alb.ingress.kubernetes.io\/healthcheck-*<\/code> on its paths\u2014great for heterogeneous backends. (AWS Documentation<\/a>)<\/li>\n\n\n\n
Multiple hostnames can map to the same ALB<\/strong>. Use ExternalDNS records (CNAME\/Alias) for each host. (Pattern often seen in multi-namespace single-ALB setups.) (Stack Overflow<\/a>)<\/li>\n\n\n\n
Ensure at least one Ingress (often the anchor) declares listen-ports<\/code> for predictable listeners; some users hit quirks without it. (GitHub<\/a>)<\/li>\n<\/ol>\n\n\n\n
\n\n\n\nMigration recipe (from many ALBs \u2192 one ALB)<\/h2>\n\n\n\n
\n
prod-ing<\/code>) and create the anchor<\/strong> Ingress with desired scheme\/listeners\/target-type<\/strong>. (AWS Documentation<\/a>)<\/li>\n\n\n\ngroup.name: prod-ing<\/code> and a unique group.order<\/code>.<\/li>\n\n\n\n
\n\n\n\nQuick test plan<\/h2>\n\n\n\n
\n
curl -I https:\/\/api.example.com\/vehicle\/healthz<\/code> \u2192 expect 200 from apps\/vehicle<\/code>.<\/li>\n\n\n\ncurl -I https:\/\/ops.example.com\/metrics\/<\/code> \u2192 expect 200 from ops\/metrics<\/code>.<\/li>\n\n\n\n900<\/code>) and confirm it doesn\u2019t<\/strong> shadow specific rules.<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nFAQ<\/h2>\n\n\n\n
A: Yes\u2014set those annotations on each Ingress; they apply to that Ingress\u2019s paths only. (AWS Documentation<\/a>)<\/p>\n\n\n\ninternet-facing<\/code> and internal<\/code> in the same group?<\/strong>
A: No. Those are ALB-level attributes<\/strong>; split into separate groups\/ALBs. (AWS Documentation<\/a>)<\/p>\n\n\n\n