Re: Does Raft orderer work across multiple Kubernetes clusters?

Alexandre Pauwels

I've said it before on this mailing list and I guess I'll say it again, I don't understand this hate with k8s and Fabric.

Using nginx and coredns you can achieve nearly any sort of routing combination you want. The ONLY port that needs to be exposed to the outside world is 443, any endpoint on any internal pod can be defined as a subdomain and routed to the correct pod internally using clusterIP services. CoreDNS rewrites are leveraged to avoid hairpinning traffic (which I don't see as's just using DNS for what it was meant to do, interpreting a hostname and routing it to the appropriate IP, no more no less).

To answer the original question: yes, RAFT orderers on multiple clusters absolutely CAN communicate with each other AND identify each other using TLS certificate pinning, and without exposing anything other than the default port 443. Select an ingress which supports TLS passthrough/L4 routing (nginx supports this just fine). Enable passthrough on your ingress resource. Define your ingress to route a particular subdomain to a specific port on your orderer's service.

I think putting down leveraging k8s to host Fabric is harmful to Fabric adoption as a whole. K8s is an apt host of Fabric services.


On Tue, Nov 19, 2019, 17:08 Nye Liu <nye@...> wrote:
This is precisely why k8s and p2p are never a good match. K8s simply breaks far too many networking rfcs. It is suitable for asymmetric client/server microservices or stacks, and even then a tiny subset of networking protocols.

On Tue, Nov 19, 2019, 1:47 PM Yueming Xu <yxucolo@...> wrote:
If I have 2 orgs contributing orderer nodes using etcd raft consensus, and each org runs its nodes in its own Kubernetes cluster.  How can I make Raft work across these 2 orgs? I guess that every orderer node will have to make some ports open to outside of its K8s cluster via e.g., ELB, but I am not sure which port and whether all orderer nodes must be open to public.  Is there a concept like the anchor peer, where each org need to make only the anchor peer open to external world?

Or, should I simply make all orderer nodes live in the same Kubernetes cluster as a best practice?  Thanks.

Join to automatically receive all group messages.