# Connect to Elasticsearch with TransportClient **URL:** \ **Category:** Elastic Cloud on Kubernetes (ECK)\ **Created:** [February 11, 2020, 2:54pm UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795 "2020-02-11T14:54:40Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Sebastien\_Falquier](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebastien_falquier/32/47746_2.png) [@Sebastien\_Falquier](https://discuss.elastic.co/u/Sebastien_Falquier)\ **Post date:** [February 11, 2020, 2:54pm UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/1 "2020-02-11T14:54:40Z")
Hello, Even if java TransportClient is deprecated, I need to connect on port 9300 to an elasticsearch cluster deployed with ECK operator. Devops team has worked to open port 9300 on quickstart-es-http service so that it looks like this : > ``` > apiVersion: v1 > kind: Service > metadata: > creationTimestamp: "2020-01-17T10:33:56Z" > labels: > common.k8s.elastic.co/type: elasticsearch > elasticsearch.k8s.elastic.co/cluster-name: quickstart > name: quickstart-es-http > namespace: default > ownerReferences: > - apiVersion: elasticsearch.k8s.elastic.co/v1 > blockOwnerDeletion: true > controller: true > kind: Elasticsearch > name: quickstart > uid: dd235882-3914-11ea-b5af-42010a8401b1 > resourceVersion: "209164059" > selfLink: /api/v1/namespaces/default/services/quickstart-es-http > uid: dd27e974-3914-11ea-b5af-42010a8401b1 > spec: > clusterIP: 10.47.249.165 > ports: > - name: http > port: 9200 > protocol: TCP > targetPort: 9200 > - name: inc > port: 9300 > protocol: TCP > targetPort: 9300 > selector: > common.k8s.elastic.co/type: elasticsearch > elasticsearch.k8s.elastic.co/cluster-name: quickstart > sessionAffinity: None > type: ClusterIP > status: > loadBalancer: {} > > ``` ... but I still cannot connect to the cluster with the TransportClient (famous NoNodeAvailableException) whereas I have no problem to connect with the java high level REST client. Any tips to fix this issue? ---
**Author:** ![sebgl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebgl/32/48702_2.png) [@sebgl](https://discuss.elastic.co/u/sebgl)\ **Post date:** [February 13, 2020, 2:19pm UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/2 "2020-02-13T14:19:28Z")
Hello, Can you give more details about your transport client setup? Which URL does it use to connect to the nodes, which certificates, etc. The service looks correct to me, but we would need to spend some time trying to reproduce with the transport client, which is deprecated. ---
**Author:** ![Sebastien\_Falquier](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebastien_falquier/32/47746_2.png) [@Sebastien\_Falquier](https://discuss.elastic.co/u/Sebastien_Falquier)\ **Post date:** [February 14, 2020, 8:58am UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/3 "2020-02-14T08:58:11Z")
I am trying to connect an opensource service called ARLAS-server which instantiate TransportClient [here](https://github.com/gisaia/ARLAS-server/blob/964a4ae5800346b36097cd4480dacc4cded50976/arlas-server/src/main/java/io/arlas/server/app/ArlasServer.java#L253-L292) and depends on elasticsearch 7.3.2. I think it should work properly without enabling ssl (i.e. no XPackTransportClient) and without sniffing... but it cannot connect. To fix this, I tried different client setup available with ARLAS-server, but none of them is working. I deploy ARLAS-server container in the same GKE cluster and use the following config : - transport adress : quickstart-es-http:9300 - cluster.name : quickstart ---
**Author:** ![sebgl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebgl/32/48702_2.png) [@sebgl](https://discuss.elastic.co/u/sebgl)\ **Post date:** [February 18, 2020, 9:24am UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/4 "2020-02-18T09:24:54Z")
I'm not familiar at all with ARLAS-server. A few things that may help you: - Are you able to reach the Elasticsearch port from your ARLAS-server container? You could try with something like `nc -vz quickstart-es-http 9300`. - According to [that piece of code](https://github.com/gisaia/ARLAS-server/blob/964a4ae5800346b36097cd4480dacc4cded50976/arlas-server/src/main/java/io/arlas/server/app/ArlasServer.java#L253-L292) it looks like you can use SSL. Which is enabled by default. To verify the Elasticsearch server certificate you may need to provide the `ca.crt` stored in the `-es-transport-certs-public` Kubernetes secret. ---
**Author:** ![Sebastien\_Falquier](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebastien_falquier/32/47746_2.png) [@Sebastien\_Falquier](https://discuss.elastic.co/u/Sebastien_Falquier)\ **Post date:** [February 20, 2020, 10:09am UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/5 "2020-02-20T10:09:59Z")
ARLAS-server container is able to reach Elasticsearch cluster on transport port (9300), that was one of the first things I checked when facing the NoNodeAvailableException. We have switched off TLS on the cluster to avoid additional connection problem, but maybe it's only switched off for http (9200) and not for transport (9300). By reading [this](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-accessing-elastic-services.html#k8s-tls-certificates), it looks like transport layer is not configurable with ECK, right? By the way, it looks like the cluster does not store the certificate you have mentioned : > ``` > % kubectl get secret | grep es-transport > % > % kubectl get secret | grep es-http > % > > ``` Maybe it's the root cause of my issue, but I cannot find documentation to fix it. ---
**Author:** ![sebgl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebgl/32/48702_2.png) [@sebgl](https://discuss.elastic.co/u/sebgl)\ **Post date:** [March 2, 2020, 9:41am UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/6 "2020-03-02T09:41:19Z")
> By reading [this](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-accessing-elastic-services.html#k8s-tls-certificates), it looks like transport layer is not configurable with ECK, right? That's correct. > By the way, it looks like the cluster does not store the certificate you have mentioned Hm this is weird, can you double check you are in the correct namespace? Do you see any ECK-managed secret at all? ---
**Author:** ![Orfeas0](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/orfeas0/32/69686_2.png) [@Orfeas0](https://discuss.elastic.co/u/Orfeas0)\ **Post date:** [June 4, 2020, 7:49am UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/7 "2020-06-04T07:49:35Z")
If the transport layer is not configurable with ECK, does that mean that remote clusters cannot be used with ECK? Reminding that to connect to a remote cluster, one needs to use the transport (9300) port, not http port (9200). Any workarounds? ---
**Author:** ![Anya\_Sabo](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/anya_sabo/32/49903_2.png) [@Anya\_Sabo](https://discuss.elastic.co/u/Anya_Sabo)\ **Post date:** [June 4, 2020, 6:54pm UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/8 "2020-06-04T18:54:18Z")
Please see the remote cluster documentation: [https://www.elastic.co/guide/en/cloud-on-k8s/1.1/k8s-remote-clusters.html](https://www.elastic.co/guide/en/cloud-on-k8s/1.1/k8s-remote-clusters.html) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 4, 2022, 7:44am UTC](https://discuss.elastic.co/t/connect-to-elasticsearch-with-transportclient/218795/9 "2022-11-04T07:44:29Z")