lightbend
Support exposing HTTP/2 services though an ingress
HTTP2 on GKE ingresses is supported, but requires some additional configuration (see https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-http2, kubernetes/ingress-gce#18
We should document how to expose a HTTP/2 service via an ingress, which is especially relevant for exposing gRPC services.
This might also require code changes: for example, it might require using HTTPS on the client->ingress side of the connection. Also, the gRPC infrastructure currently returns a '404' for '/', we might need to change that to '200' to make health checks succeed.
The GKE Ingress for HTTP(S) Load Balancing can be configured with either HTTP or HTTPS on the 'outside'. When using HTTP on the 'outside', HTTP/2 is not supported.
The protocol used between the Ingress and the Service can be either HTTP, HTTPS or HTTP2. This is determined by the cloud.google.com/app-protocols annotation. HTTP2 here means HTTP2 over HTTPS.
When using HTTPS on the 'outside' and HTTP for the communication with the service, using HTTP/2 does not work.
This suggests that for HTTP/2 to work all the way from the client to the service, you must use HTTPS on the 'outside' and HTTP/2 over HTTPS for the communication with the service. Presumably you cannot use just any TLS certificate, but must use one signed by the cluster root CA, which AFAICS means generating a CSR and setting up a process to get it signed automatically on pod startup (https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#create-a-certificate-signing-request).
The (currently pre-GA) Istio ingress (https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/) or ingress gateway (https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/) might be a more interesting way to approach this.
(I think we can close this after merging #746, and create separate tickets if there's particular additional things we'd like to support)