An optimization of the network communication architecture for improving the running of hyperledger fabric on kubernetes, where the random port of the pod affects the node's p2p communication

[JasonCeng]

Current Status

When running Hyperledger Fabric with Kubernetes, the port of the node's pod is random, while the ports of the Orderer and Peer anchor nodes are written in the genesis block gennis.block. When the node is restarted, the port will change, which will cause the node to be unable to establish p2p communication.

Expected

In order to improve the orchestration and deployment capabilities of Hyperledger Fabric on kubernetes, it is recommended to optimize the network communication architecture.

Solution

Introduce Zookeeper as a decentralized registration center, and each organization maintains a registration center. The specific design is as follows:

1. Allow each organization to connect to its own Zookeeper cluster, ZNode=/hosts/{domain name}
2. The {domain name, node ip, external random port} of the blockchain node (Orderer, peer, CA) is stored on the Zookeeper cluster
3. When the blockchain node (Orderer, peer, CA) starts, it immediately reports the {domain name, node ip, external random port} of this node to ZNode
4. When the blockchain node (Orderer, peer, CA) starts, it starts to monitor all changes in /hosts/{domain name} on ZNode.
   (a) When the data changes, update the local /etc/hosts
   (b) When the data changes, update the port number for the node to establish a connection with the peer node

Please let us know if you plan to work on this.

Yes!

[yacovm]

And where would Zookeeper run? If it runs in K8S you have the same problem, and if it runs outside of it, then why can't you run Fabric outside of Kubernetes too?

[denyeart]

Can't you specify the service port when using Kubernetes and/or use an ingress with a static port?