Ingress V1: support for service backends

[jpeach]

Support Ingress V1 IngressBackend changes. The IngressBackend gets a new ServiceBackend field to replace the service name and port. It probably doesn't make sense for Contour to support backends other than Services.

https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20190125-ingress-api-group.md#alternative-backend-types

[sunjayBhatia]

The links in the issue are broken it seems, and the Ingress API seems to have settled on a more generic Resource backend: https://kubernetes.io/docs/concepts/services-networking/ingress/#resource-backend that is a TypedLocalObjectReference

[sunjayBhatia]

How do we select a port to forward traffic to with a TypedLocalObjectReference? Use the first one? Add a cluster/route for each port?

See

• IngressBackend.Resource: https://github.com/kubernetes/api/blob/v0.19.7/networking/v1/types.go
• TypedLocalObjectReference: https://github.com/kubernetes/api/blob/v0.19.7/core/v1/types.go#L5235-L5245

[sunjayBhatia]

Updated KEP link: https://github.com/kubernetes/enhancements/tree/c14615cbf22c760fd0a6cbb4e962c66260c98463/keps/sig-network/1453-ingress-api#alternative-backend-types

Support for non-Service type Resources is implementation-specific. Implmentations MUST support Kubernetes Service. Support for other types is OPTIONAL.

idk, this makes me think Services are not intended to be supported in the generic Resource field, but I could see how it could be interpreted the other way

Also:

// Service references a Service as a Backend. This is specially
// called out as it is required to be supported AND to reduce
// verbosity.

[sunjayBhatia]

Ah this is definitely already finished by #3266 which also converts v1beta1 Ingress to this format