Resolve conflicts in GRPCRoute conformance testing.

[tao12345666333]

Is there an existing issue for this?

• I have searched the existing issues

Does this enhancement require public documentation?

• I have added an Acceptance Criteria item for adding and/or adjusting public documentation (if applicable)

Problem Statement

During the process of implementing the Gateway API GRPCRoute conformance test, I found that if both tests.GRPCRouteHeaderMatching.ShortName and tests.GRPCExactMethodMatching.ShortName are running, there will be conflicts leading to a failure.

So in the PR #5776
I temporarily disabled one of them. We need to delve into why they are conflicting and resolve it.

Proposed Solution

• Understand why they would conflict.
• If there is a problem with the processing logic on the KIC side, then proceed with the repair.

Additional information

No response

Acceptance Criteria

• Allow tests.GRPCRouteHeaderMatching.ShortName and tests.GRPCExactMethodMatching.ShortName to run simultaneously during the GRPCRoute conformance test.

[tao12345666333]

In #6132, we observed that the result of GRPCRouteHeaderMatching is unstable, so I disabled it and enabled GRPCExactMethodMatching

ac6a0d8

[pmalek]

GRPCExactMethodMatching also fails on CI:

2024-06-10T11:16:56.1129176Z     --- FAIL: TestGatewayConformance/GRPCExactMethodMatching (0.02s)
2024-06-10T11:16:56.1130291Z         --- PASS: TestGatewayConformance/GRPCExactMethodMatching/2_request_to_'/gateway_api_conformance.echo_basic.grpcecho.GrpcEcho/EchoThree'_should_receive_a_Unimplemented_(12) (0.01s)
2024-06-10T11:16:56.1131357Z         --- PASS: TestGatewayConformance/GRPCExactMethodMatching/0_request_to_'/gateway_api_conformance.echo_basic.grpcecho.GrpcEcho/Echo'_should_go_to_grpc-infra-backend-v1 (3.02s)
2024-06-10T11:16:56.1132435Z         --- FAIL: TestGatewayConformance/GRPCExactMethodMatching/1_request_to_'/gateway_api_conformance.echo_basic.grpcecho.GrpcEcho/EchoTwo'_should_go_to_grpc-infra-backend-v2 (30.00s)

https://github.com/Kong/kubernetes-ingress-controller/actions/runs/9447263257/job/26018780527

[tao12345666333]

After a series of attempts, I want to summarize the current situation.

The GRPCExactMethodMatching test case uses https://github.com/kubernetes-sigs/gateway-api/blob/56df48e829b70c9b7ae4769c4d4d5b47b302774f/conformance/tests/grpcroute-exact-method-matching.yaml#L1-L23

This means routing different methods to different backend services.

Note: Some gRPC clients (typically CLI clients) issue “gRPC Reflection Requests” as a means of determining what methods a server exports and how those methods are called. These requests have a particular path. For example, /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo is a valid reflection path. As with any proxy request, Kong needs to know how to route these requests. In the current example, they would be routed to the catch-all route whose path is /, matching any path. If no route matches the gRPC reflection request, Kong will respond, as expected, with a 404 Not Found response.

via https://docs.konghq.com/gateway/latest/production/configuring-a-grpc-service/

According to the instructions in the document, when Kong Gateway is performing gRPC proxying, it needs to create a catch-all route to respond to gRPC Reflection Requests. When creating different catch-all routes for two services, in fact, since they are completely identical except for the service being different, Kong does not define their behavior unless priority is manually added for control.

[tao12345666333]

Considering these factors, and since it is a traditional mode, I think we can close this issue.

For Kongers who want to see more information about this, you can check here: https://kongstrong.slack.com/archives/C03CTMSHP6C/p1718863712895609