Is it possible to have the controller to only create a new alb if there isn't one already associated with the ingress host?
reason:
I have one hostname, but the services I want to create rules for are in different namespaces, so I'm using multiple ingress objects, but each ingress object creates a new alb and updates the route53 DNS record to the point the most recent one
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-namespaceAuth
namespace: auth
spec:
rules:
- host: apps.example.com
http:
paths:
- path: /service1InAuthNS/*
backend:
serviceName: service1
servicePort: 443
- path: /service2InAuthNS/*
backend:
serviceName: service2
servicePort: 443
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-namespaceMonitoring
namespace: monitoring
spec:
rules:
- host: apps.example.com
http:
paths:
- path: /service3InMonitoringNS/*
backend:
serviceName: service3
servicePort: 443
- path: /
backend:
serviceName: service4
servicePort: 443
Today you can't. Each ingress resource represents a new ALB.
However, these seems reasonable and would add some great flexibility into the controller's usage.
We should consider it for #11.
Thanks @joshrosso, looking forward to this. Will also give us the flexibility of using the alb.ingress.kubernetes.io/backend-protocol annotation to configure both HTTPS and HTTP targetGroup protocols on one alb
Unfortunately, I don't see this making it to 1.0, although we will have host based routing.
Going to slate it for 1.1 as it's still a cool idea, just makes mapping quite a bit more complex.
Using Helm templating for all our applications, and it seems creating an ingress file per chart is how it does it. But a $20 per month ALB per app seems expensive so this would definitely be better in my mind.
@joshrosso Any update?
Seems related: https://github.com/coreos/alb-ingress-controller/issues/298
Closing this and tracking the feature request in #298
Most helpful comment
Today you can't. Each ingress resource represents a new ALB.
However, these seems reasonable and would add some great flexibility into the controller's usage.
We should consider it for #11.