Question

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

这是场景：

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

stuffButton

问题在于每个吊舱都会有不同的事实：

NODE_SEED
验证者列表

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

为此配置创建配置图
使用无头服务创建有状态集（3个副本），以实现Pod（stellar-0，stellar-1，stellar-2 ...等）之间的稳定可达性

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

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

我想知道是否有更好的解决方案/模式可用于此目的，而不是运行配置完全相同的服务，而配置与作为单独实体（状态集，部署..）的配置略有不同，这些实体通过这些对等体使用各自的服务将会可用（但是这种失败会破坏使用启用复制的kubernetes高级资源的目的）？

谢谢

Answer 1

因此，您可以拥有一个ConfigMap，其中包含多个密钥，每个密钥唯一地代表一个副本。您还可以将StatefulSet与initContainer一起使用来部署您的Pod，以设置配置。这只是一个示例（您必须根据需要对其进行调整）：

ConfigMap：

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> ]

StatefulSet：

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

希望有帮助！

Answer 2

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

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

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

将Kube用于区块链网络具有价值；但是如果部署验证器（和启动节点）感觉不符合实际，那是因为它不完全适合ReplicaSet模型。

哪种Kubernetes模式适合点对点配置略有不同的点对点场景？

2 个答案: