3

我正在尝试在 Kubernetes 上运行私有恒星区块链基础设施（不加入现有的公共或测试恒星网络），但我的问题可以概括为在 Kubernetes 上运行任何对等服务的场景。因此，我将尝试以一种概括的方式来解释我的问题（希望它可以产生适用于在 kubernetes 上运行的任何类似拓扑的答案）。

这是场景：

我想运行 3 个节点（用 kube 术语：pod），它们能够以分散的方式相互通信，但问题在于每个节点的配置略有不同。通常，配置如下所示（这是 pod0 的示例）：

NETWORK_PASSPHRASE="my private network"

NODE_SEED=<pod0_private_key>

KNOWN_PEERS=[
    "stellar-0",
    "stellar-1",
    "stellar-2"]

[QUORUM_SET]
VALIDATORS=[ <pod1_pub_key>, <pod2_pub_key> ]

问题在于每个 pod 会有不同的事实：

  • NODE_SEED
  • 验证者名单

我的第一个想法（在意识到这个问题之前）是：

  • 为此配置创建配置映射
  • 使用无头服务创建 statefulset（3 个副本）以实现 pod 之间的稳定可达性（stellar-0、stellar-1、stellar-2...等）

另一个想法（在意识到这个问题之后）是：

  • 为每个对等体创建单独的配置映射
  • 使用服务创建 statefulset（1 个副本）

我想知道是否有任何更好的解决方案/模式可以用于此目的，而不是运行完全相同的服务，配置略有不同作为单独的实体（statefulset，deployment..），它们的单独服务可以通过这些对等点可用（但是这种方式违背了使用支持复制的 Kubernetes 高级资源的目的）？

谢谢

4

2 回答 2

6

因此，您可以拥有一个ConfigMap具有多个键的单个键，每个键都对您的副本之一唯一意味着。您还可以使用 a 部署您的 podStatefulSet来initContainer设置配置。这只是一个示例（您必须根据需要对其进行调整）：

配置图：

apiVersion: v1
kind: ConfigMap
metadata:
  name: stellar
  labels:
    app: stellar
data:
  stellar0.cnf: |
    NETWORK_PASSPHRASE="my private network"    
    NODE_SEED=<stellar0_private_key>    
    KNOWN_PEERS=[
        "stellar-0",
        "stellar-1",
        "stellar-2"]    
    [QUORUM_SET]
    VALIDATORS=[ <stellar1_pub_key>, <stellar2_pub_key> ]

  stellar1.cnf: |

    NETWORK_PASSPHRASE="my private network"
    NODE_SEED=<stellar1_private_key>
    KNOWN_PEERS=[
        "stellar-0",
        "stellar-1",
        "stellar-2"]

    [QUORUM_SET]
    VALIDATORS=[ <stellar0_pub_key>, <stellar2_pub_key> ]

  stellar2.cnf: |

    NETWORK_PASSPHRASE="my private network"
    NODE_SEED=<stellar2_private_key>
    KNOWN_PEERS=[
        "stellar-0",
        "stellar-1",
        "stellar-2"]

    [QUORUM_SET]
    VALIDATORS=[ <stellar0_pub_key>, <stellar1_pub_key> ]

有状态集：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: stellarblockchain
spec:
  selector:
    matchLabels:
      app: stellar
  serviceName: stellar
  replicas: 3
  template:
    metadata:
      labels:
        app: stellar
    spec:
      initContainers:
      - name: init-stellar
        image: stellar-image:version
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Generate config from pod ordinal index.
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          # Copy appropriate conf.d files from config-map to emptyDir.
          if [[ $ordinal -eq 0 ]]; then
            cp /mnt/config-map/stellar0.cnf /mnt/conf.d/
          elif [[ $ordinal -eq 1 ]]; then
            cp /mnt/config-map/stellar1.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/stellar2.cnf /mnt/conf.d/
          fi
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map

      containers:
      - name: stellar
        image: stellar-image:version
        ports:
        - name: stellar
          containerPort: <whatever port you need here>
        volumeMounts:
        - name: conf
          mountPath: /etc/stellar/conf.d <== wherever your config for stellar needs to be

     volumes:
     - name: conf
       emptyDir: {}
     - name: config-map
       configMap:
         name: stellar

服务（如果您需要公开它）

apiVersion: v1
kind: Service
metadata:
  name: stellar
  labels:
    app: stellar
spec:
  ports:
  - name: stellar
    port: <stellar-port>
  clusterIP: None
  selector:
    app: stellar

希望能帮助到你！

于 2018-09-24T04:09:50.877 回答
1

值得一提的是：Kube 的主要优势是管理相同 Pod 的可扩展工作负载。这就是 Kube API 中存在 ReplicaSet 的原因。

区块链验证器节点不是相同的 Pod。他们不是匿名的；它们由需要唯一私钥的公共地址标识。

从这个意义上说，作为 RPC 节点的区块链节点更简单；它们可以被复制，并且 RPC 请求可以在节点之间循环。

将 Kube 用于区块链网络是有价值的；但如果部署验证器（和引导节点）感觉违背了常规，那是因为它不完全适合 ReplicaSet 模型。

于 2019-12-27T21:17:08.043 回答