How to test client connection with fdb EKS

how to test client connection with fdb EKS

Can you add some more context here? This is a very generic question. Are those clients running in the same EKS cluster, outside of EKS, in the same namespace, outside of AWS, in different AWS account/VPC?

In general you can test connectivity by getting the connection string from the FoundationDBCluster status and in the most simplest case you use fdbcli to connect to the cluster.

basically i want to test by deploying the client myself in the same EKS cluster… with this file , so i just need to copy this file and apply it ?

Using the Deployment from this file should be enough if you already have a cluster running. You have to adjust the name of the ConfigMap that should be mounted by the deployment.

do u mean this part ? also after adding these details ? how to test the connection with the client ?

  • configMap:
    - key: cluster-file
    path: fdb.cluster
    name: test-cluster-config
    name: config-map
    • emptyDir: {}
      name: dynamic-conf

what is this part ? do we need to change this ?

  • emptyDir: {}
    name: dynamic-conf

any help is appreciated

The dynamic-conf is used to copy the fdb client libraries to the client: fdb-kubernetes-operator/config/tests/client/client.yaml at main · FoundationDB/fdb-kubernetes-operator · GitHub

This line must be updated: fdb-kubernetes-operator/config/tests/client/client.yaml at main · FoundationDB/fdb-kubernetes-operator · GitHub in the example the expectation is that the created cluster was called test-cluster, if the name is different you have to modify it.

thanks, i got the client.yaml deployed and got 2 pods for client.
now how do we test the connections from client to fdb ? i got into the client pod and did fdbcli and it did not work.

these are my pods now
msubramanyam@FAN-J44M6R9FG4 ~ % kubectl get pods -n platform-fdb
test-cluster-client-f6d9d54b8-9tdx9 1/1 Running 0 31h
test-cluster-client-f6d9d54b8-cdz82 1/1 Running 0 31h
test-cluster-cluster-controller-1 2/2 Running 0 6d10h
test-cluster-log-1 2/2 Running 0 6d10h
test-cluster-log-2 2/2 Running 0 6d10h
test-cluster-log-3 2/2 Running 0 6d10h
test-cluster-log-4 2/2 Running 0 6d10h
test-cluster-new-cluster-controller-1 2/2 Running 0 6d10h
test-cluster-new-log-1 2/2 Running 0 6d10h
test-cluster-new-log-2 2/2 Running 0 6d10h
test-cluster-new-log-3 2/2 Running 0 6d10h
test-cluster-new-log-4 2/2 Running 0 6d10h
test-cluster-new-storage-1 2/2 Running 0 6d10h
test-cluster-new-storage-2 2/2 Running 0 6d10h
test-cluster-new-storage-3 2/2 Running 0 6d10h
test-cluster-storage-1 2/2 Running 0 6d10h
test-cluster-storage-2 2/2 Running 0 6d10h
test-cluster-storage-3 2/2 Running 0 6d10h

root@test-cluster-client-f6d9d54b8-cdz82:/app# fdbcli -C /var/dynamic-conf/fdb.cluster
Invalid cluster file `/var/dynamic-conf/fdb.cluster’: 2104 Connection string invalid


root@test-cluster-client-f6d9d54b8-cdz82:/app# cat /var/dynamic-conf/fdb.cluster

root@test-cluster-client-f6d9d54b8-cdz82:/usr/bin# fdbcli -v
FoundationDB CLI 6.1 (v6.1.12)
source version 90ba203c166c62ae9173b2523081a0c6afaa1604
protocol fdb00b061060001

not sure i am trying the right thing


what is the expectation from client.yaml

The sample App I basically this one: foundationdb/packaging/docker/samples/python at main · apple/foundationdb · GitHub, you should be able to make the according API calls from that document.

You are using DNS names in the connection string, so it is expected that your fdbcli version 6.1 is not working as the DNS support was added in 7.0. The fdbcli binary should be under /var/dynamic-conf (see: fdb-kubernetes-operator/config/samples/client.yaml at main · FoundationDB/fdb-kubernetes-operator · GitHub), if you use the fdbcli version 7.0+ connecting to the cluster should work.

Since you’re using DNS names in the connection string, you want to use this client config: fdb-kubernetes-operator/config/tests/dns/client.yaml at main · FoundationDB/fdb-kubernetes-operator · GitHub (it is basically the same as the other one but not copying the 6.3 library and binaries, as those are useless for DNS connection strings).

The DNS limitation are documented here: fdb-kubernetes-operator/docs/manual/ at main · FoundationDB/fdb-kubernetes-operator · GitHub

FDB supports to use DNS in the cluster file since 7.1 and the operator can make use of that

ok thanks, so do i also need the Kind: service part in this file ?

fdb-kubernetes-operator/config/tests/dns/client.yaml at main · FoundationDB/fdb-kubernetes-operator · GitHub.

Previously u said only deployment section is enough

Only the Deployment section is needed. You can use the port-forward command from kubectl to access the APIs: Use Port Forwarding to Access Applications in a Cluster | Kubernetes

thanks , will try tas u siggested , but one more question,
what is this part in the client.yaml and why we dont need it

apiVersion: v1
kind: Service
name: test-cluster-client
app: test-cluster-client
app: test-cluster-client
type: LoadBalancer
- port: 9562
targetPort: 5000

This will create a Kubernetes service to expose the test client, depending on the configuration of your Kubernetes cluster, this might expose the application to the public internet. There is no need for this, as you can access the client application with the port-forwarding feature: Use Port Forwarding to Access Applications in a Cluster | Kubernetes.

JFYI: I removed the service in this PR: Remove the client service in the sample by johscheuer · Pull Request #1772 · FoundationDB/fdb-kubernetes-operator · GitHub as it seems to add additional confusion and is not required.

thanks for your clarification, in our case we are going to have the ingress.yaml to to expose the application, i think that will serve the same purpose , is that correct?