Extract out networking.internal.knative.dev.ClusterIngress

[tcnghia]

Expected Behavior

We have ClusterIngress that cleanly separates out our Istio Gateway / VirtualService dependency.

Actual Behavior

We are generating VirtualServices from our Route which has strong coupling with Configuration/Revision.

[lichuqiang]

/cc

[josephburnett]

@tcnghia, I would also expect that ClusterIngress would specify the desired queuing behavior for requests which exceed the capacity of the Revision or an individual Pod. E.g. #1846.

@mattmoor, what do you think?

[tcnghia]

@josephburnett I'd like to start out from what we can do first. I'd love to discuss more about the queuing capacity needed and follow up with an improvement.

[tcnghia]

Plan of implementation based on last WG meetup:

1. Introduce internal type networking.internal.knative.dev/v1alpha1/ClusterIngress
2. Enable validation of ClusterIngress in the webhook.
3. Reconcile ClusterIngress into VirtualService (PoC).
4. Add ./pkg/reconciler/route/resources/ingress.go (PoC) to make a ClusterIngress from a Route.
5. Switch ./pkg/reconciler/route/route.go (PoC) to:
   5.1. create ClusterIngress instead of VirtualService.
   5.2. create placeholder Service based on ClusterIngress.Status.LoadBalancer output.

[lichuqiang]

Would like to pick up the reconciler tasks once we get the API merged

[lichuqiang]

/assign

[mattmoor]

@tcnghia @lichuqiang Is there more work left here? I think we've landed at least the scope I wanted for 0.2.

[lichuqiang]

We'll need to consider refactoring the ingress reconciler, hopefully to decouple it from the main controller.
But we can close this, and open a new issue to track that.

[mattmoor]

This was about building the abstraction, and not about decoupling Istio.

thanks again, @lichuqiang !!!!! 🎉