哪种Kubernetes模式适合于对等场景中的对等点配置略有不同的情况？

Question

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

下面是一个场景：

我想运行3个对等点( kube术语: pods)，它们能够以分散的方式相互通信，但问题在于，每个对等点的配置略有不同。通常，配置如下(这是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> ]

问题在于每个豆荚都会有不同的：

• NODE_SEED
• 验证器列表

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

• 为此配置创建配置映射
• 创建状态集(3个副本)与无头服务，以使稳定的可达之间的豆荚(恒星-0，恒星-1，恒星-2.等)

另一个想法(在认识到这个问题之后)是：

• 为每个对等点创建单独的配置映射
• 使用服务创建状态集(1个副本)

我想知道是否有更好的解决方案/模式可用于此目的，而不是运行与单独实体(状态集、部署.)配置略有不同的完全相同的服务。通过他们单独的服务，这些对等点将是可用的(但这种类型的服务违背了使用kubernetes高级资源的目的，而这种资源支持复制)？

谢谢

Answer 1

因此，您可以拥有一个带有多个键的ConfigMap，每个键都是为一个副本唯一指定的。您还可以使用带有StatefulSet的initContainer来部署您的吊舱，以建立信任关系。这只是一个例子(您必须根据需要调整它)：

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的主要优势是管理相同Pods的可伸缩工作负载。这就是为什么库贝API中存在ReplicaSet的原因。

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

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

将Kube用于块链网络是有价值的；但是，如果部署验证器(和引导节点)感觉有悖常理，那是因为它不太适合ReplicaSet模型。