Fix Issue #257 by including additional details on Kube Service routing

[jkneubuh]

Signed-off-by: Josh Kneubuhl jkneubuh@us.ibm.com

Type of change

• Documentation update

Description

This PR adds a brief summary of Kubernetes Service routing as a mechanism to implement basic HA / DR / connection load balancing to the Fabric Gateway.

Additional details

A sample integration of the Kube routing is available in the Kubernetes Test Network HA GUIDE

Kube test network updates to enable gateway client load balancing are available in fabric-samples PR #532

Related issues

Additional discussion, and the original issue, is tracked at fabric-gateway issue #257

Resolves #257

[denyeart]

This is great information and I am primarily interested in getting the content captured somewhere/anywhere for now. It does go deeper into Kubernetes than I was expecting, that's not a bad thing, but it does beg the question of how we want to evolve the docs to be more aligned with Kubernetes going forward. We could inject such content throughout the docs as done here, or we could keep the load balancing concepts fairly generic in the core Fabric topics, and talk about Kubernetes specifics somewhere else like in the Deployment Guide topics. Again, without a wider Kubernetes doc strategy in place yet, I'm happy to keep the content here for now, and then potentially shift it to somewhere like Deployment Guide later once we have the wider Kubernetes doc strategy. Thought we could at least start the discussion here though.

Let's see if documentation specialists such as @joshhus and @denali49 have any thoughts on the topic.

And we probably want @mbwhite to provide a technical review as well.

[mbwhite]

an observation: is it worth pushing the gateway client strongly here? a) make them well known. but also b) this approach works due to the way gateway has a single point of (network) contact with Fabric. Really not sure this would well with previous SDKs?

[mbwhite]

... in addition to the peerX.orgY hostname

[jkneubuh]

Hi @denyeart and @joshhus - I did a little word smithing in here and moved the Kube-specific content out of the Gateway configuration guide. The section now hangs as a top-level sub-section under the Deployment Guide on read-the-docs.

I tried to emulate the multi-layer links using the deploypeer/*.md and deployorderer/*.md files as an example, but it doesn't sit right. For example, under "Creating a peer" there is a page of content, with a nav list at the bottom that links to the sub-pages under deploypeer/*.md. This doesn't seem like the right fit for the Kubernetes Considerations, which feels like it should be captured as a long-and-growing list of things to keep in mind when deploying to cloud. I.e.. the kube considerations seems like it should be a two-level nav on the left-navbar, rather than a three-level nav like deploypeer and deployorderer sections.

Dave is this a little closer to what you were envisioning?

[denyeart]

@jkneubuh Going through old issues and PRs, I realized we need to finish this one out.

There is some good guidance now in https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/01-FabricGateway.md#production-deployment-of-fabric-gateway.

We should determine how to best convey this information across Fabric docs and the full stack asset transfer docs.

[mbwhite]

@denyeart @jkneubuh

I've got some additional information that could be used to extend this as well.

[julian-trustgrid]

Hi guys,

Just chiming on as I'm having issues regarding load balancing into multiple deployment pods. I have created a kubernetes service, a client application which communicates to the kubernetes service via gRPC.

I'm tailing the logs of the kube service and noticed that only one peer is getting a request. Is it because the client application is maintaining the connection hence the request is not getting routed to other peers?

Thank you