Problems using grpcs in ingress nginx about ingress-nginx

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[longwuyuan]

/remove-kind bug
/kind support
/triage needs-information

• I tested with this https://kubernetes.github.io/ingress-nginx/examples/grpc/ and i did not find problems using gRPC
• If gRPC works, then gRPCS also works
• The issue description is not detailed enough to reproduce the problem
• The issue description does not contain answers to questions that are asked in the template of a bug report so any comments will be based on guesses
• You can help by first testing the example linked above
• To test the example above for readers to understand the problem to be solved, you need to configure a vanilla minikube luster with metallb or a kind cluster as documented and tested in the CI

[strongjz]

• host: my-svc.cluster-01.my-domain.com

Could you let me know if you are making GRPC calls with that as the host header?

is my-svc.cluster-01.my-domain.com setup to map to 100.68.113.2?

grpcurl -cert tls.cert -key tls.key -cacert ca.crt -proto svc.proto -d '{}' my-svc.cluster-01.my-domain.com:8443 mysSvc/GetHealth
Failed to dial target host "my-svc.cluster-01.my-domain.com:8443": tls: first record does not look like a TLS handshake

I think that should my-svc.cluster-01.my-domain.com:443 0r 100.68.113.2:443 with the host header set for my-svc.cluster-01.my-domain.com

[github-actions]

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

[longwuyuan]

The basic information in issue description states ;

• No LB service to terminate the TLS for the ingress
• SSL-Passthrough annotation seen in ingress

None of these 2 are clear proof that GRPC is broken. I even tested a normal grpc hello-world app.

Why use ssl-passthrough if ingress is expected to support GRPC(S) ?

Why Use GRPCS backend-protocol if there is no TLS termination on a LB in front of the controller and and the ingress is configured for ssl-passthrough ?

There is no traction and not enough information here to show a problem with the controller. I will close this for now as there are too many issues lingering with no traction and no clear problem description. Please re-open when you are ready to re-engage with data that shows a problem on the controller.

/close

[k8s-ci-robot]

@longwuyuan: Closing this issue.

In response to this:

The basic information in issue description states ;

• No LB service to terminate the TLS for the ingress
• SSL-Passthrough annotation seen in ingress

None of these 2 are clear proof that GRPC is broken. I even tested a normal grpc hello-world app.

Why use ssl-passthrough if ingress is expected to support GRPC(S) ?

Why Use GRPCS backend-protocol if there is no TLS termination on a LB in front of the controller and and the ingress is configured for ssl-passthrough ?

There is no traction and not enough information here to show a problem with the controller. I will close this for now as there are too many issues lingering with no traction and no clear problem description. Please re-open when you are ready to re-engage with data that shows a problem on the controller.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.