Custom backend targets

[hermanbanken]

We would like to use:

• GCP CloudRun services / Cloud Functions serverless backends
• GCS Storage Buckets

in conjunction to GKE resources in the same Load Balancer.

The documentation (https://gateway-api.sigs.k8s.io/) mentions (emphasis mine):

Typed Routes and typed backends - The Gateway API supports typed Route resources and also different types of backends. This allows the API to be flexible in supporting various protocols (like HTTP and gRPC) and various backend targets (like Kubernetes Services, storage buckets, or functions).

As far as I can tell this hasn't been implemented, or I just can't find the references to it. Does support exist? How could we contribute such a thing, or would that need to be done by vendors?

[howardjohn]

This would need to be done by an implementation (technically it doesn't have to be Google that does it, although you would need to fully re-implement the GKE Implementation which is probably not fun).

cc @robscott for GKE support

[robscott]

Unfortunately I can't commit to any timeline here, but this is something we're working to be able to express in GKE. Like John mentioned, implementing support for something like this is ultimately up to implementations, but we may be able to define some common patterns that can be used with Gateway API to reference custom backends.

[dprotaso]

Given that we know implementations know how to route to K8s Services we could provide an extension mechanism to allow third parties to resolve backend ref CRDs to K8s Services. This could be used generically by gateway implementations.

eg. For Knative we know a Knative Service will map to a Kubernetes Service of the same name

I don't know what this mechanic/mapping would be exactly - but it would make the ecosystem very pluggable without requiring implementations to add support for everything

(this would be for in-cluster targets)

[theRealWardo]

is there any clarity around common patterns here? I suspect the general idea is of the Gateway API is to reference a CRD that the gateway implementation supports. obviously support would be implementation specific but here's my best guess for a cloud function backend reference as an example:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - backendRefs:
    - group: cloud.google.com
      kind: CloudFunction
      name: example-func

is this in the right ballpark?

[youngnick]

Yes, that's about what we intended. There's no clarity around common patterns yet, because not many implementations (to my knowledge) have done much in this area. Or, at least, if some have, they haven't told us about it.

[dprotaso]

What does sending traffic to a storage bucket look like?

[howardjohn]

For a GCP LB specific implementation: there is native support in GCP LB for "Storage bucket" that takes some optimized paths, etc.

For generic implementation: probably would not support a *.gke.io API, but if they did presumably it would be translating into a URL like https://storage.googleapis.com/<bucket>/<file> I guesss?

[dprotaso]

Good point it's essentially a resolution from a K8s Resource to a URL.

Knative uses this approach using a duck type we call 'Addressable' - https://github.com/knative/pkg/blob/0f52db700d6331c379b81d64fa9c6efe6a108e82/apis/duck/v1/addressable_types.go#L68

It's used in our eventing system - so people can send events to any Addressable (some resource with a status.address.url)

Special use case is K8s Services