I have created a knative service[gRPC server] in aks cluster, I have exposed the service using istio gateway private static IP,
After using the command kubectl get ksvc I have got an address sample-app.test.10.153.157.156.sslio.io
When I try to use this address in the python client, it throws error saying failed to connect addresses, but if I try to hit the service using
curl sample-app.test.10.153.157.156.sslio.io I am able to hit the service, I don't know what i am missing here.. please suggest..
GRPC uses HTTP/2. You may need to explicitly name your port h2c. I'm assuming that you've tested the container locally without Knative in the path and have been able to make a grpc call in that case.
Related
I have a Python gRPC server running on AWS Fargate (configured very similar to this AWS guide here), and another AWS Fargate task (call it the "client") that attempts to make a connection to my gRPC server (also using Python gRPC). However, the client is unable to make a call to my server, with the following error:
<_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "failed to connect to all addresses"
debug_error_string = "{"created":"#1619057124.216955000","description":"Failed to pick subchannel",
"file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":5397,
"referenced_errors":[{"created":"#1619057124.216950000","description":"failed to connect to all addresses",
"file":"src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc",
"file_line":398,"grpc_status":14}]}"
Based on my reading online, it seems like there are myriad situations in which this error is thrown, and I'm having trouble figuring out which one pertains to my case. Here is some additional information:
When running client and server locally, I am able to successfully connect by having the client connect to localhost:[PORT]
I have configured an application load balancer target group following the guide from AWS here that makes health check requests to the / route of my gRPC server, using the gRPC protocol, and expect gRPC response code 12 (UNIMPLEMENTED); these health check requests are coming back as expected, which I believe implies the load balancer is able to successfully communicate with the server (although I could be misunderstanding)
I configured a service discovery system (following this guide here) that should allow me to reach my gRPC server within my VPC via the name service-name.dev.co.local. I can confirm that the corresponding DNS record exists in Route 53, and when I SSH into my VPC, I am indeed able to ping service-name.dev.co.local successfully.
Anyone have any ideas? Would appreciate any and all advice, and I'm happy to answer any further questions.
Thank you for your help!
on your grpc server use 0.0.0.0:[port] and expose this port with TCP on your container.
I'm testing gRPC with .NetCore and looked up for a GUI tool or something that can help me to test my endpoint like testing REST API.
I found a proxy tool: grpc-json-proxy that can be used with Postman tool (also found another GUI tool: grpcox).
Using any tool gives an error like the following when trying to connect to the endpoint:
unable to do request err=[Post
http://localhost:5001/greet.Greeter/SayHello: dial tcp 127.0.0.1:5001:
connect: connection refused]
Any idea what could be the issue?
Most importantly, are you confident the gRPC server is listening on localhost:50051? You may confirm this (on Linux) using:
GRPC="50051"
ss --tcp --listening --processes "sport = :${GRPC}"
NOTE you may need to sudo ss ... to get the process
Or more simply:
telnet localhost 50051
If you get Connected to... that's a good sign
Then, if you're using either of these tools through docker, you'll need to ensure the container can access the host's 50051 port. To do this, run the container use --net=host. This will make the host's port available to the container.
I use grpCurl
A client is running our C# gRPC client on a corporate network, behind an HTTP proxy. The http_proxy environment variable is configured, but nevertheless he sees an error message Name resolution failure when attempting to connect to the server on the internet.
DNS resolution from the same machine works fine using nslookup.
Any ideas what I can do to investigate this problem?
You can use the following three lines at application startup to configure the detailed logging that #JanTattermusch suggested:
Environment.SetEnvironmentVariable("GRPC_TRACE", "api");
Environment.SetEnvironmentVariable("GRPC_VERBOSITY", "debug");
Grpc.Core.GrpcEnvironment.SetLogger(new Grpc.Core.Logging.ConsoleLogger());
In order to connect a C# gRPC client on a corporate network, behind an HTTP proxy, add this on the client main method works:
Environment.SetEnvironmentVariable("NO_PROXY", "127.0.0.1");
I am using apache KafkaConsumer in my Scala app to talk to a Kafka server wherein the Kafka and Zookeeper services are running in a docker container on my VM (the scala app is also running on this VM). I have setup the KafkaConsumer's property "bootstrap.servers" to use 127.0.0.1:9092.
The KafkaConsumer does log, "Sending coordinator request for group queuemanager_testGroup to broker 127.0.0.1:9092". The problem appears to be that the Kafka client code is setting the coordinator values based on the response it receives which contains responseBody={error_code=0,coordinator={node_id=0,host=e7059f0f6580,port=9092}} , that is how it sets the host for future connections. Subsequently it complains that it is unable to resolve address: e7059f0f6580
The address e7059f0f6580 is the container ID of that docker container.
I have tested using telnet that my VM is not detecting this as a hostname.
What setting do I need to change such that the Kafka on my docker returns localhost/127.0.0.1 as the host in its response ? Or is there something else that I am missing / doing incorrectly ?
Update
advertised.host.name is deprecated, and --override should be avoided.
Add/edit advertised.listeners to be the format of
[PROTOCOL]://[EXTERNAL.HOST.NAME]:[PORT]
Also make sure that PORT is also listed in property for listeners
After investigating this problem for hours on end, found that there is a way to
set the hostname while starting up the Kafka server, as follows:
kafka-server-start.sh --override advertised.host.name=xxx (in my case: localhost)
Not sure if it's just a coincidence or a bug but after updating to 0.9.2 I lost my remote connections to any of my Meteor apps. localhost:3000 works fine but remote access to host:3000 or any other port I try cannot connect.
I had exactly the same symptoms with the new Meteor (0.9.2.1), I was able to connect fine on my development server using localhost:3000, but I received an error when attempting to connect to that server using the NETBIOS name (which I have been doing successfully since Blaze). Example URL:
v-as-nodejs:3000
This worked fine before but does not with the latest Meteor.
I was also able to overcome this issue by specifying an IP address and port explicitly in the Meteor server startup command:
meteor --port 192.168.1.108:3000
What is interesting is that it seems as long as the IP address in the --port parameter matches the private network address of the server, you can still connect to your server using a logical name. In my case, my server is in a DMZ on my private network, and I can use the public domain name to get to the server. I can also use the server's NETBIOS name, both work fine.
I don't fully understand why this would work unless node.js or Meteor is doing some internal comparison. It is certain though that this is a matter of either the Meteor upgrade or the Node.js upgrade.
Use --port:host:port
example: meteor run --port:192.168.168.164:6969
Binding to a specific IP seems to solve the problem:
meteor run -p 192.168.2.3:8080