Decide how to handle mutliple Ingress definitions
Suppose that we have:
- more than one Ingress defined in a namespace
- all of these specify
varnish
in thekubernetes.io/ingress.class
annotation - all of them specify the same Varnish Service with the
ingress.varnish-cache.org/varnish-svc
annotation (which we use to disambiguate the correspondence of Ingress to Service, if necessary)
Then we have more than one Ingress to be implemented by Varnish. This issue is currently mentioned on the front-page README as a ToDo under "WORK IN PROGRESS".
This situation is notoriously unspecified by the k8s standard, and the various current implementations of Ingress handle it in different ways. The FAQ for voyager (haproxy-based Ingress) has a good discussion of this in its FAQ (last question):
https://github.com/appscode/voyager/blob/master/docs/concepts/overview.md
- nginx-based implementations (both the k8s standard and the nginxinc project) "merge" the Ingresses, and implement them with the same deployment
- voyager and GCE create separate Services for each Ingress
We don't create Services on the fly for an Ingress -- the Service is created in a separate step. So the options seem to be:
- "merge" Ingresses as in the nginx solutions
- reject multiple Ingresses as an error
- let the "last Ingress win"
The voyager FAQ has some good reasons against merging, among them:
- The order of URL paths for the same Host is significant -- if more than one path matches for the same Host, take the first path that matches. This is specified by the k8s standard. But if two Ingresses foresee the same Host, then what is the order of the path rules?
Suppose that one Ingress has this:
rules:
- host: example.com
http:
paths:
- path: /foo/bar
# [...]
And the another one has:
rules:
- host: example.com
http:
paths:
- path: /foo/.*/baz
# [...]
Then how do they merge? Within one Ingress, the ordering rule disambiguates the overlapping paths. But in separate Ingress definitions, which one counts as "first"?
OTOH possibly in favor of merging:
- The nginx implementations appear to be the most widely used and most commonly known, so the "merge" solution may be what most users likely expect.
- Anecdotally, k8s users I've spoken to do in fact seem to expect the merge.
Other considerations:
- Due to the asynchronous nature of k8s, "let the last Ingress definition win" may be poorly defined -- which one is "last" is underdetermined, and what the controller sees as "last" may not match users' perceptions.
So: what's our solution?