概述
Fabric 是 Hyperledger 超级账本中的一个子项目，由 Linux 基金会主办。它提供了一个开发区块链应用程序的框架。在 2017 年 1 月份 Fabric v1.0 发布，人们急于使用 Fabric 构建区块链应用程序来解决他们的业务问题。然而，由于部署和管理 Fabric 体系过于复杂，遇到很多的困难。在 v1.0 发布之后，时隔一年，在今年 7 月份，Fabric v1.2 版本发布。
为了简化操作，我们需要一些工具来帮助我们更好地管理 Fabric 分布式系统。Kubernetes 看起来似乎是理想的平台。需要注意的是，Kubernetes 是 CNCF 基金会下的头牌项目，并且 Linux 基金会也是 CNCF 基金会的成员之一。
首先，Fabric 建议是运行在 Docker 容器中的。它的 chaincode（智能合约）也利用容器运行在 sandbox 中。 Fabric 系统由在多个容器中运行的组件组成。 另一方面，Kubernetes 正在成为自动化、容器化应用程序的部署、扩展和管理的事实上的标准。两者有天然的契合。
其次，Fabric 组件可以通过在 Kubernetes 上部署来实现高可用性。 Kubernetes 有一个名为 replicator 的功能，可以监控运行的 pod 并自动修复崩溃的 pod。
第三，Kubernetes 支持多租户。我们可以在同一个 Kubernetes 平台上运行多个隔离的 Fabric 实例。 这有利于区块链应用程序的开发和测试。
在以下部分中，我们介绍了在 Kubernetes 上部署 Fabric 的方法。 我们假设读者具有 Fabric，Docker 容器和Kubernetes 的基本知识。
网络拓扑
我们的网络拓扑结构如 图1 所示。物理网络由蓝线表示。 Kubernetes 有一个或多个主节点和工作节点。除此之外，我们还有一台 CMD 机器作为客户端来发布部署命令。 NFS 服务器用作配置文件和其他数据的共享文件系统。所有这些节点都通过物理网络（例如192.168.0.1/24）连接。
Kubernetes 的网络模型使所有 pod 都可以直接相互连接，无论它们在哪个节点上。通过使用 Kubernetes 的 CNI 插件，例如 Flannel，可以很容易地为此目的创建覆盖网络。如 图1 中的红线所示（Flannel 组件的一些细节被省略），Kubernetes 将所有 Pods 连接到 Flannel 网络，允许这些 Pods 的容器正确地相互通信。
可以在附加配置文件中指定 Flannel 网络的 IP 地址范围以及 kube_dns 的 IP 地址。我们需要确保 kube_dns 的 IP 地址必须在指定的地址范围内。例如，在 图1 中，Flannel 网络是 10.0.0.1/16，kube_dns 地址是 10.0.0.10。
Fabric 组件和 Pods 映射关系
Fabric 是一个包含多个节点的分布式系统。 节点可以属于不同的组织。 如 图2 所示，每个组织都有自己的 Peers 节点集（为简单起见，并未显示所有节点）。 Orderers 还组建了一个公共共识服务。 要将 Fabric 部署到 Kubernetes，我们需要将所有组件转换为 Pod 以进行部署，并使用命名空间来隔离组织。
在 Kubernetes 中，命名空间是一个重要的概念。 它用于在多个用户之间划分群集资源。 在 Fabric 中，可以将组织映射到名称空间，以便它们具有其专用资源。 在此映射之后，可以通过域名区分每个组织的 Peers。 此外，我们可以通过设置网络策略来隔离不同的组织。
如 图2 所示，假设 Fabric 网络中有 N 个 Peer 组织和 M 个 Order 组织。 以下是我们如何在Kubernetes 上划分它们：
组织
我们为第 N 个对等组织分配名称 orgN。 它在 Kubernetes 中的相应命名空间也称为 orgN。 Fabric orgN 的所有组件都将放入 Kubernetes 的命名空间 orgN 中。 每个组织的命名空间下都有多个 Pod。 Pod 是 Kubernetes 中的部署单元，它由一个或多个容器组成。 我们可以将每个组织的 Fabric 容器捆绑到几个 Pod 中。 这些 Pod 类型如下：
- Peer Pod：包含 Fabric peer、couchDB （可选，默认是 levelDB）、代表组织的 peer 节点。 每个组织可以有一个或多个 Peer Pods。
- CA Server Pod：组织的 Fabric CA Server 节点。 通常，一个组织中需要一个 CA Pod。
- CLI Pod：为命令行工具提供操作组织节点的环境，Fabric 的 Peer 环境变量在此 Pod 中配置（可选）。
共识排序
Fabric 中可能有一个或多个 Orderers。 我们将第 M 个订购者组织的名称设置为 orgordererM。 它在 Kubernetes 上的相应命名空间是 orgordererM。 它有一个或多个 Pod 来运行 orderer 节点。
整体拓扑
如果 Kafka 用于共识过程，我们可以将 Kafka 放入单独的命名空间。 它仅用于运行和管理 Zookeeper 和 Kafka 容器。
总而言之，整体部署如下所示：
共享存储
在部署 Fabric 之前，我们需要准备其组件的配置文件，例如 Peer 和 Orderer。这是一个非常复杂的过程，往往容易出错。幸运的是，我们创建了一个工具来自动生成这些配置文件。生成的文件存储在 NFS 等共享文件系统中。
当我们稍后启动 Fabric 的 Pod 时，我们将不同的配置文件子集安装到 Pod 中，以便它们具有特定于其所属组织的配置。
在 Kubernetes 中，我们可以使用持久卷（PV）和持久卷声明（PVC）将文件或目录挂载到 Pod 中。我们为 Fabric 中的每个组织创建 PV 和 PVC，以实现资源隔离。每个组织只应在 NFS 服务器中看到自己的目录。
在创建 PV 之后，我们定义 PVC，以便 Fabric 节点可以使用 PV 来访问相应的目录和文件。
以对等组织 org1 为例。首先，我们创建一个命名空间 org1 及其 PV。 PV 映射到 NFS 上的目录 / opt/share/crypto-config/peerOrganizations/org1。其次，我们创建一个 PVC 来消耗 PV。命名空间 org1 下的所有 pod 使用相同的 PVC。但是，我们只通过在 pod 配置文件中指定安装路径，将必要的文件映射到每个 pod 中。
图6 显示了 Pod 与 NFS 共享目录之间的关系。变量 $PVC 表示 PVC 挂载点，在此示例中为 /opt/share/crypto-config/peerOrganizations/org1。
通信
当所有 Fabric 的组件都放入 Kubernetes 的 Pod 中时，我们需要考虑这些 Pod 之间的网络连接。 Kubernetes 中的每个 Pod 都有一个内部 IP 地址，但是很难使用 IP 和端口在 Pod 之间进行通信，因为 IP 地址对于 Pod 来说是短暂的。 当 Pod 重新启动时，其 IP 地址也会发生变化。 因此，有必要在 Kubernetes 中为 Pod 创建服务，以便它们可以通过服务名称相互通信。 服务的命名应遵循以下原则来显示它所绑定的 Pod 信息：
- 服务和 Pod 的名称空间应该是一致的。
- 服务名称应与 Pod 中容器的 ID 一致。
例如，Fabric 的组织 org1 的 peer0 映射到命名空间 org1 下名为 peer0 的 Pod。 绑定到它的服务应该命名为peer0.org1，其中 peer0 是服务的名称，org1 是服务的名称空间。 其他 Pod 可以通过服务名称 peer0.org1 连接到 org1 的 peer0，该名称显示为 peer0 的主机名。
具体的部署过程请看第二部分。