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

Question

我正在尝试运行 kubernetes 上的私有恒星区块链基础设施（不加入现有 public 或测试恒星网络）但我的问题可以推广到运行在 kubernetes 上设置任何点对点服务。因此，我将尝试以通用的方式解释我的问题（希望它可以产生适用于任何类似拓扑的答案运行ning on the 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> ]

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

NODE_SEED
验证者列表

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

为此配置创建配置映射
使用无头服务创建有状态集（3 个副本）以在 pods（stellar-0、stellar-1、stellar-2...等）

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

为每个节点创建单独的配置映射
使用服务创建有状态集（1 个副本）

我想知道是否有更好的 solution/pattern 可用于此目的，而不是运行将完全相同的服务与单独的实体（statefulset、部署.. ) 以及它们单独的服务，通过这些服务可以使用这些对等点（但这种方式违背了使用 kubernetes 高级资源实现复制的目的）？

谢谢

Answer 1

因此，您可以拥有一个 ConfigMap 和多个密钥，每个密钥都对您的一个副本具有唯一意义。您还可以使用 StatefulSet 和 initContainer 来部署您的 pods 来设置配置。这只是一个示例（您必须根据需要对其进行调整）：

配置图：

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

希望对您有所帮助！

Answer 2

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

中的原因

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

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

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

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

Which Kubernetes pattern is appropriate for the peer to peer scenario where peers have slightly different configuration?

peer

kubernetes

stellar