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

問題在於每個 pod 會有不同的：

• 節點_種子
• 驗證者列表

我的第一個想法（在意識到這個問題之前）是：

• 為此配置創建配置映射
• 使用無頭服務創建 statefulset（3 個副本），以實現 pod（stellar-0、stellar-1、stellar-2...等）之間的穩定可達性

另一個想法（在意識到這個問題之后）是：

• 為每個對等點創建單獨的配置映射
• 使用服務創建 statefulset（1 個副本）

我想知道是否有任何更好的解決方案/模式可以用於此目的，而不是運行完全相同的服務，配置略有不同，作為單獨的實體（狀態集，部署..），通過它們的單獨服務可以使用這些對等點（但這種破壞了使用能夠復制的 kubernetes 高級資源的目的）？

謝謝

Answer 1

因此，您可以擁有一個帶有多個鍵的單個ConfigMap ，每個鍵都唯一地用於您的一個副本。 您還可以使用StatefulSet和initContainer來部署您的 pod 來設置配置。 這只是一個示例（您必須根據需要對其進行調整）：

配置映射：

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 的主要優勢是管理相同 Pod 的可擴展工作負載。 這就是 Kube API 中存在 ReplicaSet 的原因。

區塊鏈驗證器節點不是相同的 Pod。 他們不是匿名的； 它們由需要唯一私鑰的公共地址標識。

從這個意義上說，充當 RPC 節點的區塊鏈節點更簡單； 它們可以被復制並且 RPC 請求可以在節點之間循環。

將 Kube 用於區塊鏈網絡是有價值的； 但是，如果部署驗證器（和啟動節點）感覺有悖常理，那是因為它沒有完全適合 ReplicaSet 模型。