Example of a http/2 gRPC application connected through envoy/contour #379
Comments
|
The issue reported here appears to be the same #364. |
|
This is likely to be #378 TL;DR I think the |
|
@davecheney Thanks for the reply! TL;DR
EnvoyProxy ConfigurationThat difference between Looking at envoy proxy configuration, I believe the case described is usually (or can be) handled by registering both I put together a foolish patch that would stub in both entries. Defining an ingress, now produces a set of routes that looks like this "route_table_dump": {
"name": "ingress_https",
"virtual_hosts": [
{
"name": "yages.mydomain.com",
"domains": [
"yages.mydomain.com",
"yages.mydomain.com:443"
],
"routes": [
{
"match": {
"prefix": "/"
},
"route": {
"cluster": "default/yages/grpc",
"timeout": "5s"
}
}
]
}
]
}
"route_table_dump": {
"name": "ingress_http",
"virtual_hosts": [
{
"name": "yages.mydomain.com",
"domains": [
"yages.mydomain.com",
"yages.mydomain.com:80"
],
"routes": [
{
"match": {
"prefix": "/"
},
"route": {
"cluster": "default/yages/grpc",
"timeout": "5s"
}
}
]
}
]
}grpcurl -v -insecure -protoset internal/servers/yages/yages.protoset yages.mydomain.com:443 yages.Echo.PingResolved method descriptor:
{
"name": "Ping",
"inputType": ".yages.Empty",
"outputType": ".yages.Content",
"options": {
}
}
Request metadata to send:
(empty)
Response headers received:
date: Mon, 14 May 2018 19:45:18 GMT
server: envoy
content-type: application/grpc
x-envoy-upstream-service-time: 1
Response contents:
{
"text": "pong"
}
Response trailers received:
(empty)
Sent 0 requests and received 1 response
I cross-checked the envoy configuration above against istio's route definition for ingress (I'm evaluating several options as part of a planned k8s build out. I'd prefer contour over istio). The envoy routes configuration also contains 2 entries:
Are you interested in a patch?! |
|
Thanks for your diagnosis, I appreciate the work you've put into this. I'm wary of accepting a patch for this without more time to consider the implications of this, see #210 |
|
If you want to work on this my suggestion would be to talk to the Envoy authors and see if adding additional domains for :80, and/or :443 is a reasonable workaround for envoyproxy/envoy#1269. My outstanding concerns are:
|
|
Please see #390 |
|
I'm going to close this as a duplicate of #390. Please comment if you think there is something I have not captured. |
|
@davecheney closing sounds like a good plan. You've captured it all! 👍 |
I've been following allow this issue, #152, the result of which was to expose upstream protocol configuration as an annotation on the service. I'm attempting to verify http/2 gRPC support using contour v0.5.0 and yages.
I have been able to successfully host kuard, httpbin, multiple variants of an echo both with and without TLS. However, every attempt to call a gRPC service results in an error
Kubernetes Host Environment:
gRPC Service/Source/Proto
Contour Resource Definition
Yages Resource Definition
Deploy Resources
Monitor Envoy (separate terminal)
Inspect Contour Config
Forward Proxy debug Interface
Inspect Routes/Clusters
Send Requests
With the protoset to avoid reflection
I'm stymied 😃 . Why is there no cluster match for the URL? I have a route that matches the URL and maps to a cluster in my routes definition ....
The only other interesting information is that if I curl or point my browser that the same URL, I see slightly different behavior.
In terms of interesting differences, the method, authority, and scheme are slightly different.
For fun, I built my own gRPC client to call ping
Who has ideas? Or can point out my foolish mistake? Can someone provide an example of a HTTP/2 gRPC service connected through contour/envoy?
The text was updated successfully, but these errors were encountered: