Plans for bolt+routing for external access to neo4j cluster

This is not so much a question about how to do something, more a question about how are things going to evolve in the futur.
Right now, accessing a causal cluster deployed with kubernetes is complicated. The difficulties I encountered while doing this are related to the bolt protocol.

The first difficult is to make the bolt protocole go through an Ingress. With the nginx ingress controller this is not possible and the ingress controller must be by passed. The Neo4j Browser must be connected directly to the load balancer through a port opened for it. It means that for each cluster another port must be opened. [Quick Edit] I did not stress the fact that by passing the ingress controller makes it difficult to use TLS.

The second difficulty is related to the protocol bolt+routing. Even after solving the previous difficulty one will face the problem of accessing the master node in order to run write operations. For this I haven't found a proper solution so far. When running Kubernetes with a Kubernetes provider, I have no control over my nodes IPs so I can't use a NodePort. I have to use a LoadBalancer.

The question : how are things going to evolve ? Is there plans to make the bolt protocol more friendly with orchestrations tools such as K8s ?

Hi,

I've deployed neo4j with helm3 in a k8s 1.17 cluster (hosted by ovh.com)

helm install --namespace neo4j db stable/neo4j --set imageTag=4.0.3

The service accessing the DB are running in the same cluster so no need for ingress or LB.
But for dev purpose, I'm developing on a remote bastion outside the cluster, so I port forward some ports like that

kubectl port-forward -n neo4j service/db-neo4j 7474:7474 7687:7687

And if I want to use neo4j browser on my local PC via my working bastion to inside the cluster, I'm also running on my local pc (win10 with WSL)

ssh -v -L 7474:localhost:7474 -L 7687:localhost:7687 <bastion>

The whole path is
<local pc>---ssh tunnel---<remote bastion>---kubectl port-forward---<k8s cluster>

all trafic is encrypted

In production, everything run inside the cluster

Our product management folks are right now looking at how we can improve support for Kubernetes, and I'll pass this along to them. I agree, that bolt+routing is problematic outside of Kubernetes. Neo4j in general uses a "smart client" routing architecture where the bolt client needs to know the cluster topology in order to route queries appropriately, and this clashes a bit with the Kubernetes model of wanting to treat all pods as completely interchangeable, when in database architectures they just aren't.

I can't give you much in terms of what form this better support will take, or what the timeline is. I can offer that some people have developed proxies to sit in the middle and expose a service outside, while others have gone with working with the Kubernetes primitives themselves to try and expose the service. Both approaches have some drawbacks.

Over time, a completely different approach would be to go with a Kubernetes operator which would simplify this in a number of ways - these various topics are under discussion.

Hey hey! Update to this thread. We've recently released updated helm charts.

In this repo there is a directory called external exposure that provides full worked examples of how to expose bolt+routing / neo4j querying outside of kubernetes

This repo is a variant of the old "helm repo", which has been deprecated. The repo linked here is maintained.