rgrandl
commented
3 months ago We've decided not to do this change. Setting up ingress automatically is tricky because different users may have different requirements. For now, if someone wants to use ingress, they should make the public listeners also private, and manually update the ingress rules to switch traffic to the new version of the app.
The users of the kube deployer have complained that a load balancer per public listener is expensive. Also, using a load balancer service is quite limiting in terms of functionality (e.g., doesn't allow https traffic, to specify TLS rules, etc.)
This PR adds an ingress resource to route external traffic to the application.
If the user specifies hostnames for their public listeners, we'll create an ingress resource that will forward the external traffic to each public listener, based on their hostnames. Otherwise, we'll keep the existing behavior, where each public listener is reachable via a load balancer.
Note that we create a single ingress resource per application (unique name). I.e., when the user rolls out a new version of the app, the traffic will be instantaneously migrated to the new version of the app.
An alternative would be to create an ingress per application version. However, this doesn't really work unless the routing rules include subpaths that are app version specific. This would require the user to control the routing rules. However, this is possible if the user will manually edit the generated manifest for the ingress.