Closed onmomo closed 8 months ago
I'm trialing telepresence and hit the same issue with a demo gRPC service.
I found a comment buried in a thread on the community Slack. You can set the appProtocol
to grpc
or http2
on the service's port to hint to Telepresence that the port is HTTP/2 based. It works around the autodetection failure for me.
Example:
apiVersion: v1
kind: Service
metadata:
name: api-svc
spec:
ports:
- name: api
port: 8080
targetPort: 8080
appProtocol: grpc # or http2
selector:
app: api-svc
Would be very nice if this could be added to documentation somehow. It took me multiple days to find this issue on github.
@CleverUnderDog it is present in the documentation, under App Protocol Selection. If you have suggestions on how to make this easier to find, please let us know and we'll consider it.
@CleverUnderDog it is present in the documentation, under App Protocol Selection. If you have suggestions on how to make this easier to find, please let us know and we'll consider it.
So when I read about this whole topic and tried to find information on how to use intercepts with grpc/http2 I generally landed here a couple of times: Intercepts I would personally find it helpful to have some kind of reference to additional information/configuration parameters when I first read about a topic.
@JWKartheiser ^^ is perhaps something to consider for the docs improvements?
We hit this bug too. Part of the reason it's so insidious is that it doesn't show up until you create an intercept, then leave the intercept:
telepresence intercept test --mechanism=tcp --mount=false --workload buildkitd --namespace cloud-build-proxy --port 1235
telepresence leave test
# after this, the grpc deployment stops working
our mental model of K8s v1.Service is that it's usually a TCP load balancer and doesn't know much about L7. Maybe the fix is that when you telepresence leave
the intercept, you should get a warning like:
$ telepresence leave test
WARNING: Switching the traffic agent from TCP to HTTP. To get rid of this warning, set the Service's `appProtocol` to match whether your pod uses http or http2
Closing this, because I believe the original problem is fixed in traffic-agent version 1.14.4.
Describe the bug The port 3000 is actually an akka-grpc service that is configured to use http2 but it seems that traffic agent is unable to detect it. As soon as the traffic agent sidecar is running, grpc calls to the service running in the cluster are failing.
There is no active intercept
requests to our akka-grpc service in the cluster fail due to
traffic agent logs
Started with an intercept of 8080:http and then removed the intercept leaving the traffic agent container running
note, traffic agent does not detect http2 service while doing
GET /telepresence-http2-check
This seems misleading since the service does not really listen to port 3000 while the traffic agent gets added since the main pod gets restarted in the process? Will traffic agent repeat this check from time to time?
Expected behavior If traffic agent is installed for the workload, grpc request are served via http2 to cluster service correctly
Versions (please complete the following information):