Ingress controller does not add a rule that matches the host and the port

[pbchekin]

Describe the bug
Gloo in ingress mode adds an Envoy rule that matches a host specified in Ingress, but does not add a rule that matches a host and a port (80 or 443). This creates an issue for proxying GRPC services, because most of the standard GRPC clients (grpcurl, Go, Python) use GRPC endpoint for :authority header, if authority is not explicitly specified.

For example:

grpcurl -plaintext example.com:80 list

sends the corresponding request:

:method: POST
:scheme: http
:path: /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo
:authority: example.com:80
content-type: application/grpc
user-agent: grpc-go/1.29.0
te: trailers

As a result, a GRPC request does not work with Gloo ingress-proxy (other methods fail with similar message):

Failed to list services: server does not support the reflection API

As a workaround, every client needs to explicitly specify authority:

grpcurl -plaintext -authority example.com example.com:80 list

sends the corresponding request:

:method: POST
:scheme: http
:path: /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo
:authority: example.com
content-type: application/grpc
user-agent: grpc-go/1.29.0
te: trailers

Envoy has the following configuration:

      ...
      {
        "name": "example_com-http",
        "domains": [
         "example.com"
        ],
        ...
      },
      ...

To Reproduce

1. Create a deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: books
  name: books
spec:
  selector:
    matchLabels:
      app: books
  template:
    metadata:
      labels:
        app: books
    spec:
      containers:
      - image: docker.io/soloio/example-store-grpc:v1
        args:
        - --service=books

2. Create a service

apiVersion: v1
kind: Service
metadata:
  labels:
    app: books
  name: books
spec:
  type: ClusterIP
  ports:
  - port: 9999
    targetPort: 8080
    name: grpc-port
  selector:
    app: books

3. Verify that the GRPC service works

kubectl port-forward svc/books 9999:9999 # run in a separate terminal
grpcurl -plaintext 127.0.0.1:9999 list

4. Create an ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: books
  labels:
    app: books
  annotations:
    kubernetes.io/ingress.class: gloo
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: books
          servicePort: 9999

5. The same GRPC service does not work via Ingress

grpcurl -plaintext example.com:80 list

However it works when we specify authority:

grpcurl -plaintext -authority example.com example.com:80 list

Expected behavior
While explicitly specifying authority for a GRPC client is a potential workaround, sometimes it not possible to modify 3rd party GRPC applications or libraries. For such cases, Gloo in ingress mode should support their default behavior.

Gloo in ingress mode should add two Envoy rules: first for the Ingress host, second for the Ingress port and port.

The corresponding Envoy configuration must be:

      ...
      {
        "name": "example_com-http",
        "domains": [
         "example.com",
         "example.com:80"
        ],
        ...
      },
      ...

Additional context

• Gloo version: 1.4.1

[pbchekin]

Note that some ingress controllers, such as Contour, do add an Envoy rule to mach host and port.

[lmakarov]

This is still a valid issue with Gloo Edge 1.8.6. cc @pbchekin, @kdorosh

I ran into this issue while following the Gloo Edge gRPC tutorial.

The only difference between the tutorial steps and what I did was specifying the domain for the VirtualService.
The resulting envoy config looks like this in my case:

      "virtual_hosts": [
       {
        "name": "gloo-system_default",
        "domains": [
         "<ip>.nip.io"
        ],

Testing with grpcurl

# Default
$ grpcurl -plaintext <ip>.nip.io:80 list 
Failed to list services: server does not support the reflection API

# With authority set
$ grpcurl -plaintext -authority <ip>.nip.io <ip>.nip.io:80 list
grpc.reflection.v1alpha.ServerReflection
solo.examples.v1.StoreService

If I drop the domain from the VirtualService config, then the envoy config looks like this and everything works (since now the domain is "*"):

      "virtual_hosts": [
       {
        "name": "gloo-system_default",
        "domains": [
         "*"
        ],

Additional context

$ glooctl version     
Client: {"version":"1.8.0"}
Server: {"type":"Gateway","kubernetes":{"containers":[{"Tag":"1.8.6","Name":"discovery","Registry":"quay.io/solo-io"},{"Tag":"1.8.6","Name":"gateway","Registry":"quay.io/solo-io"},{"Tag":"1.8.6","Name":"gloo-envoy-wrapper","Registry":"quay.io/solo-io"},{"Tag":"1.8.6","Name":"gloo","Registry":"quay.io/solo-io"}],"namespace":"gloo-system"}}

[pbchekin]

@lmakarov right, looks like a regression. Unfortunately the corresponding test was also updated and that regression was not identified.

[pbchekin]

@lmakarov the gRPC tutorial you mentioned is not related to Ingress and also it explicitly states that you have to specify authority to make it work. I agree that this is still a problem, but I would recommend to create a new issue.