Service Discovery and OpenShift/Kubernetes
196 views
Skip to first unread message
Jerry Thome
Feb 28, 2019, 10:32:19 AM2/28/19
to vert.x
I'm am trying out the Service Discovery for the first time in OpenShift. At this point, I'm trying to get the Discovery to return any record. The application is *not* deployed in a Vertx cluster. Longer term, we are trying to get Service A to lookup Service B deployed in the same namespace (namespace=daily)
RIght now in the application, we pull in the single discovery dependency (vertx 3.6.3).
<dependency>
<groupId>io.vertx</groupId>
<artifactId>vertx-service-discovery-bridge-kubernetes</artifactId>
</dependency>
and the verticle is trying to grab any/every record. The end result is success, but no record.
@Override
public void start(io.vertx.core.Future<Void> startFuture) {
discovery = ServiceDiscovery.create(vertx);
discovery.getRecord(r -> true, ar -> {
if (ar.succeeded() ) {
if (ar.result() != null) {
logger.info("We have a record");
logger.info("Record Information: name {}, metadata {}, location {}", ar.result().getName(), ar.result().getMetadata().encode(), ar.result().getLocation());
} else {
logger.info("The lookup succeeded, but no matching service");
}
}
else {
logger.info("Failed, with cause {} {}", ar.succeeded(), ar.result());
}
});
...
}
We've been trying to follow the standard documentation: https://vertx.io/docs/vertx-service-discovery/java/#_kubernetes_bridge, but we're obviously missing something.
The output logs don't show any permission issues. In the past, we ran ```oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)```
I'm not sure how to confirm the 'oauth token' is OK. Also, is there a way to tell the bridge with namespace to use?
Thanks for any help or thoughts.
Jerry Thome
Mar 4, 2019, 7:11:30 PM3/4/19
to vert.x
Progress is made, and some confusion followed. Below I have a sample Verticle with three flavors of using Discovery to look up a service called "vertx-server" that is deployed and working in OpenShift. The first example works. The second example does not seem to interac with Kubernetes at all. And the third has a timing issue. Does anyone see a coding issue or potential bug?
After the Verticle code, I posted the results of each test. I have the basic dependencies in my pom.xml along with vertx-service-discovery-bridge-kubernetes for all three examples. I'm using Vertx 3.6.3. We are running OpenShift 3.9.
package com.example;
import io.vertx.core.logging.Logger;import io.vertx.core.logging.LoggerFactory;import io.vertx.reactivex.core.AbstractVerticle;import io.vertx.reactivex.servicediscovery.ServiceDiscovery;import io.vertx.reactivex.servicediscovery.types.HttpEndpoint;
public class ClientVerticle extends AbstractVerticle {
Logger logger = LoggerFactory.getLogger(this.getClass().getName()); @Override public void start(io.vertx.core.Future<Void> startFuture) {
String serviceName = "vertx-server";
// ===================================== // Example 1 - Works // ===================================== ServiceDiscovery.create(vertx, discovery -> // Retrieve a web client HttpEndpoint.getWebClient(discovery, svc -> svc.getName().equals(serviceName), ar -> { if (ar.failed()) { logger.error("D'oh the {} service is not available", serviceName, ar.cause()); } else { logger.info("Found {}. Result={}", serviceName, ar.result()); } }) );
// ===================================== // Example 2 - Does not find the service. Nothing in standard out from K8s. Like the bridge doesn't exist. // - What is so different about calling ServiceDiscovery separately that is doesn't use the K8 importer??? // =====================================// ServiceDiscovery discovery = ServiceDiscovery.create(vertx);// // HttpEndpoint.rxGetWebClient(discovery, svc -> svc.getName().equals(serviceName))// .subscribe(success -> {// logger.info("Retrieve WebClient {} {}", serviceName, success.toString());;// }, error -> {// logger.error("Failed to retrieve WebClient {} {}", serviceName, error);// });
// ===================================== // Example 3 // - Calling the Importer directly does retrieve service information from K8s // - But the service information is loaded after we search for the Record. // - The Importer is not 'reactive' so we have to change a few imports. :( // =====================================// ServiceDiscovery discovery2 = ServiceDiscovery.create(vertx).registerServiceImporter(new KubernetesServiceImporter(), config());// // // ======================// // All of this is to test Discovery lookup.// discovery2.getRecord(svc -> svc.getName().equals(serviceName), ar -> {// // if (ar.succeeded() ) {// if (ar.result() != null) {// logger.info("We have a record"); // logger.info("Record Information: name {}, metadata {}, location {}", ar.result().getName(), ar.result().getMetadata().encode(), ar.result().getLocation());// } else {// logger.info("The lookup succeeded, but no matching service");// }// }// else {// logger.info("Failed, with cause {} {}", ar.succeeded(), ar.result());// }// }); }
}
Example 1 - Good
...
2019-03-04 23:20:30,555 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter lambda$publishRecord$9:287 - Kubernetes service published in the vert.x service registry: {"location":{"endpoint":"http://172.20.30.95:80","host":"172.20.30.95","port":80,"root":"","ssl":false},"metadata":{"app":"vertx-server","expose":"true","group":"com.example","provider":"fabric8","version":"1.0-SNAPSHOT","kubernetes.namespace":"fss-dly","kubernetes.name":"vertx-server","kubernetes.uuid":"2405c1a1-3e96-11e9-9983-005056b87eee"},"name":"vertx-server","registration":"48788cb5-5f1f-4edd-832f-a1a7b16c89dd","status":"UP","type":"http-endpoint "}
2019-03-04 23:20:30,559 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter lambda$start$3:141 - Kubernetes importer instantiated with 26 services imported
2019-03-04 23:20:30,560 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.impl.DiscoveryImpl lambda$initialize$1:93 - Auto-registration of importer io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter@6a2fc725
2019-03-04 23:20:30,602 [vert.x-eventloop-thread-0] INFO com.example.ClientVerticle lambda$2:28 - Found vertx-server. Result=io.vertx.ext.web.client.impl.WebClientBase@41a4faf2
Example 2 - Not Found
2019-03-04 23:25:01,774 [main] TRACE io.netty.channel.nio.NioEventLoop openSelector:253 - instrumented a special java.util.Set into: sun.nio.ch.EPollSelectorImpl@3fa247d1
2019-03-04 23:25:01,775 [main] TRACE io.netty.channel.nio.NioEventLoop openSelector:253 - instrumented a special java.util.Set into: sun.nio.ch.EPollSelectorImpl@3224a577
2019-03-04 23:25:02,012 [vert.x-eventloop-thread-0] ERROR com.example.ClientVerticle lambda$2:43 - Failed to retrieve WebClient vertx-server io.vertx.core.impl.NoStackTraceThrowable: No matching record
Example 3 - Timing Issue
...
2019-03-04 23:31:15,817 [vert.x-eventloop-thread-0] INFO com.example.ClientVerticle lambda$1:63 - The lookup succeeded, but no matching service
...
2019-03-04 23:31:16,024 [vert.x-eventloop-thread-0] DEBUG io.netty.util.Recycler <clinit>:99 - -Dio.netty.recycler.ratio: 8
2019-03-04 23:31:16,115 [vert.x-eventloop-thread-0] DEBUG io.netty.handler.ssl.SslHandler setHandshakeSuccess:1528 - [id: 0xa6c3cf3e, L:/172.20.5.127:58840 - R:/172.20.16.1:443] HANDSHAKEN: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2019-03-04 23:31:16,431 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter lambda$start$2:125 - Kubernetes initial import of 26 services
...
2019-03-04 23:31:16,520 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter lambda$publishRecord$9:287 - Kubernetes service published in the vert.x service registry: {"location":{"endpoint":"http://162.20.30.95:80","host":"162.20.30.95","port":80,"root":"","ssl":false},"metadata":{"app":"vertx-server","expose":"true","group":"com.example","provider":"fabric8","version":"1.0-SNAPSHOT","kubernetes.namespace":"fss-dly","kubernetes.name":"vertx-server","kubernetes.uuid":"2405c1a1-3e96-11e9-9983-005056b87eee"},"name":"vertx-server","registration":"c76aab7d-f7c0-4e84-8712-fad69339431a","status":"UP","type":"http-endpoint "}
2019-03-04 23:31:16,526 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter lambda$start$3:141 - Kubernetes importer instantiated with 26 services imported
2019-03-04 23:31:16,526 [vert.x-eventloop-thread-0] INFO io.vertx.servicediscovery.impl.DiscoveryImpl lambda$registerServiceImporter$2:216 - Service importer io.vertx.servicediscovery.kubernetes.KubernetesServiceImporter@17de0cb started
clement escoffier
Mar 6, 2019, 2:52:16 PM3/6/19
to ve...@googlegroups.com
Hello,
The approach 3 should not be used, as the importers should only be used internally.
I will try to reproduce the 1 / 2 issues, but I’ve never seen this before.
Clement
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4921b0bc-85f3-47f0-bb87-c1c1d70ad478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages