d19a7e4b02
- Add a new label to each peer to mark which org it is in - Create new service per org, that matches this label - so the service can pick from one of multiple pods - Update the kubeproxy to give more choice of ha stratergies - Update the application configmaps and samples to refer to this new service rather than specific peers Signed-off-by: Matthew B White <whitemat@uk.ibm.com> |
||
|---|---|---|
| .. | ||
| images | ||
| APPLICATIONS.md | ||
| CA.md | ||
| CHAINCODE.md | ||
| CHANNELS.md | ||
| HIGH_AVAILABILITY.md | ||
| KUBERNETES.md | ||
| README.md | ||
| TEST_NETWORK.md | ||
Kubernetes Test Network
Starting in release 2.0, Hyperledger introduced the test-network to serve as both an accelerator and learning resource for running Fabric networks. In addition to providing a study guide for operational patterns, the test-network provided a baseline environment for members of the Fabric community to quickly get up to speed with a working, local system, author smart contracts, and develop simple blockchain applications.
While test-network provided a solid foundation for casual Fabric development, the over-reliance on Docker Compose introduced tremendous, non-trivial complexity when transitioning applications to production. Without belaboring the many issues and anti-patterns present in the Compose-based test network, we'll submit that the best path forward is to align the development and production patterns around a common orchestration framework - Kubernetes.
Similar to Fabric, Kubernetes introduces a steep learning curve and presents a dizzying array of operational
flexibility. In this guide, we'll outline the design considerations in the ./network
scripts, provide a supplement to the Fabric CA Deployment Guide,
and build up to a reference model for realistic production deployments on Kubernetes.
Ahoy!
Network Topology
The Kube test network establishes as consortium among a dedicated ordering organization and two peer organizations. Participation in the network is managed over a channel, and transactions are committed to the blockchain ledgers by invoking the asset-transfer-basic Chaincode-as-a-Service running in a shared Kubernetes namespace. Each organization maintains indepedendent TLS and ECert CAs for management of local, channel, and user MSP contexts.
