As many people pointed out, deploying FoundationDB with a container-orchestration tool, such as Kubernetes, Docker Swarm, and others can be problematic for multiple reasons. One of the main problem is the unstable nature of IP addresses. Kubernetes provides stable network IDs with its StatefulSet, but when a Pod restarts, the IP address will most certainly change.
There is a suggestion to use hostname instead and thus rely on DNS to uniquely identify nodes. However, despite that it would solve the problem on Kubernetes/Swarm, this change would introduce another potential source of failure (See wwilson answer).
My proposal would be to uniquely identify nodes with an arbitrary string that would be either generated by FoundationDB when a node starts for the first time or defined by in the config file.
The main benefit of such a solution is that it does not rely on movable parts, such as IP addresses, or DNS names to identify a node. I think that what defines a node identity is the data it carries, no matter its IP address or hostname. Moreover, because it is an arbitrary string, it would be flexible enough to allow people to still use IP addresses or DNS names if they would like to.
Now one of the problems is to reach these nodes. Here is an example of an fdb.cluster file:
Since IP, port, and TLS can change, the canonical ID would be
I am not familiar with the internal implementation of FoundationDB, so I cannot assess the impact of such a change, but I am aware that this would introduce new challenges. For example, what happen when a node B has the IP address of node A that just left the cluster. Requests between nodes would have to contain this unique identifier to check its recipient.
I would be interested to hear what the community thinks about it whether they run FoundationDB in a container or not.