-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Facing "NameResolver returned no usable address" error #14
Comments
Are you running into #11 ? Also check the debug port (:9000) to see if the exact name you're connecting is listed in the response. (It has to be exact match, as this is not DNS and there's no search domains support) |
I do not think so. I am getting the error for the first try immediately after the client has started up. Grpc
.newChannelBuilder("xds:///connector-flx.dev-services:8094", InsecureChannelCredentials.create())
.maxInboundMessageSize(20 * 1024 * 1024)
.idleTimeout(0, TimeUnit.SECONDS)
.build();
|
The name should be in the listener section. The connection URI seems to be valid. Have you remapped the port in Kubernetes Service? Either way if you could find the name in listener section it should be exactly what you need to type in the |
I'm sorry, but I couldn't get this. What should be remapped?
Should it be Is there a way to manually query the xds-server to see if the service ( |
Kubernetes Service resource can map a port on the ClusterIP to another port on the actual application. For example, one can make it so that http://servicename:80 points to port 8080 on the pod so that the pod doesn't need root/setcap to bind to port 80. If that feature is used, then you need to point to the mapped port, not actual port. It also means that similar to ClusterIP, you need to list the port in the Service resource. Without that ClusterIP will drop traffic, and in xDS it should result in name not found error. (To be extra clear, we're not using ClusterIP to implement xDS but we try to emulate ClusterIP as much as possible to make users not remembering anything extra) The URI scheme is The :9000 port output is how I'd manually query it. Follow the Listener > Route > Cluster > Endpoint/ClusterLoadAssignment and you should see the list of IP addresses associated with the listener. It might also be useful to turn on gRPC debug logging on the client (usually available as envar depending on the implementation), as the client itself do this following chain and not the xDS server (the server only dump parts of the :9000 output the client is interested in, and stream any changes to the client). |
Thank you. I can confirm that I am using the right port number. apiVersion: v1
kind: Service
spec:
type: ClusterIP
ports:
- protocol: TCP
name: grpc
port: 8094
targetPort: 8094
selector:
app: connector-flx I am attaching the output from :9000. It looks like the Cluster configuration for the Route has no edsConfig. Could this be the reason? |
edsConfig is hardcoded to be empty, so it shouldn't be the case. I wonder if this is the case: usually we set Looking at our xDS source it seems that if you set a name there might have to be named all the way, or if there is no name then it has never have a name. Could you test and let me know if that is the case |
I am facing the below error when trying to hit a server from another one. The client and server are spring boot based Java applications.
The changes I made to the app are:
-Dio.grpc.xds.bootstrap=/opt/xds_bootstrap_config.json
. The contents of the config json file being:What could be the possible reasons for this failure? How can I debug such issues?
The text was updated successfully, but these errors were encountered: