Today when using Kubernetes on AWS, ingress resources are automatically turned into AWS ELBs. AWS has recently added support for Application Load Balancers (ALBs). We need to investigate and document the setup required to use Envoy as an ingress resource on AWS, which will involve setting up an ALB.
Looking around briefly, CoreOS has open sourced an ALB Ingress Controller that we may be able to leverage.
I'm definitely interested in helping replacing the ELB used in the istio ingress controller with an ALB (cheaper, faster). We currently give the istio ingress service a load balancer which gives us an elb that we add CNAMES to, and then use hostnames in the ingresses to route traffic.
Would this change require this issue to be addressed though? If not would the istio ingress controller be replaced by the ALB Ingress controller?
This has less relevance now given that we have clearly separated L4-L6 config (gateway) and L7 config (virtual services). And that the gateway could support multiple protocols (HTTP/TCP/Mongo/etc.) - which the ALB cannot.
Also, ALB ingress implies configuring AWS ALB directly instead of using Envoy for load balancing
@rshriram With alb and aws CNI we can do load balancing on pod IPs directly. This gives multiple benefits( lower latency for sure) and deeper integration with other aws resources(Cognito, ACM, Target group alarms, etc).
If we use ALB directly and skip enovy load balancing over the publically exposed services what are the drawbacks.
Can we delegate a gateway creation to create an actual ingress such that we don't deal with the similar resources twice?
I think this is beneficial because we can use AWS ALB with WAF
Most helpful comment
I think this is beneficial because we can use AWS ALB with WAF