Ingress route rule compatibility about pilot HOT 10 CLOSED

Regarding 1st item: Ingresses in kubernetes do not define any relation (i.e. precedence) between multiple routes/virtual hosts specified within the same ingress resources. Therefore, we don't "lose" anything if mapping a single ingress into an unordered set of route rules. This is the approach I took so far in the ingress controller work.

from pilot.

from pilot.

Regarding 2nd item: adding port (numbers and/or names) into the model (e.g., under WeightedDestination seems to be the only viable way to capture user intent expressed in ingress resources. Aside from ingress rules, this can be used for rerouting traffic transparently between services (i.e., client addresses service-a:80, which is rerouted to service-b:8080 by the proxy).

from pilot.

Regarding 3rd item: ingresses allows to specify a default backend for requests that doesn't match any route. An ingress controller needs to honor that specification. If not specified, we can do anything we dim fit (reply with 404, use sidecar default route rules [what are these anyway], ...). My thinking is that 404 is the proper response for ingress traffic which do not meet any explicit user-provided routes.

from pilot.

I think we need to reconsider if a route rule spec is sufficient for ingress controller. It is not clear how to associate TLS certs, which are bound to specific hostnames, with a route rule or a destination policy. The hostname in ingress spec does not match the destination fields in route rules and policies. Moreover, the destination field in the ingress backend (service name) could benefit from applying route rules to it, to apply client side traffic shifting at the ingress proxy instead of standing up a separate proxy.

Maybe we should make ingress an explicit model element, like the route rule?
Do we lose any features that we get for free if we treat ingress rule like other route rules?

@zcahana @rshriram WDYT?

from pilot.

from pilot.

@rshriram: The Kubernetes ingress spec allows different TLS certs to be used based on host: https://github.com/kubernetes/kubernetes/blob/9497139cb62015905ba5b3d11836f2b0c117ff80/pkg/apis/extensions/types.go#L604

Currently, we map Kubernetes Ingress rules to Istio rules and we need some way to convey that information.

from pilot.

The hostname in ingress spec does not match the destination fields in route rules and policies.

Don't think it's a problem. We use the route rule's headers matching map to match on the host from ingress spec.

The destination field in the ingress backend (service name) could benefit from applying route rules to it

Definitely (#217). Does separating ingress rules and route rules will get us closer to that? I was thinking this could be somehow achieved by the ingressWatcher processing both kind of rule kinds.

One incompatibility that we do have today is that we need to pass the target service port from the ingress spec to the ingress watcher. Today we do that uncleanly via the destination tags.

As for TLS, won't we need some way to specify certs location in the model, regardless of ingress?
Maybe we need to extend the model with some CertificateStore.

from pilot.

For beta, we should define a unified ingress rule definition that covers k8s/extended ingress controllers/Istio use cases. It's clear now that we need a unified model to combine various sources of ingress definitions (k8s, deployment annotations, internal istio) that specifically covers edge traffic concerns (TLS, url/host rewriting) and that plays well with in-cluster routing.

@rshriram @zcahana

from pilot.

The ingress is going nowhere and its a PITA. We should get rid of ingress and create our own front proxy using LB ports. Besides, @kyessenov has managed to combine ingress spec with route rules for most part. Close?

from pilot.