Какой шаблон Kubernetes подходит для однорангового сценария, когда одноранговые узлы имеют немного другую конфигурацию?

Я пытаюсь запустить частную звездную инфраструктуру блокчейна на кубернетах (не для присоединения к существующей общедоступной или тестовой звездной сети), но мой вопрос можно обобщить для сценария запуска любых одноранговых служб на кубернетах. Поэтому я попытаюсь объяснить свою проблему обобщенно (в надежде, что она даст ответы, применимые к любой аналогичной топологии, работающей на кубернетах).

Вот сценарий:

Я хочу запустить 3 одноранговых узла (в терминах куба: поды), которые могут взаимодействовать друг с другом децентрализованно, но проблема заключается в том, что каждый из этих одноранговых узлов имеет немного другую конфигурацию. В целом конфигурация выглядит так (это пример для 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 реплики) с помощью безголового сервиса, чтобы обеспечить стабильную доступность между модулями (stellar-0, stellar-1, stellar-2 и т. Д.)

Другая идея (после осознания этой проблемы) заключалась бы в следующем:

  • Создайте отдельные карты конфигурации для каждого однорангового узла
  • Создать набор состояний (1 реплика) с сервисом

Мне интересно, есть ли лучшее решение / шаблон, который можно было бы использовать для этой цели, а не запускать полностью те же службы с немного другой конфигурацией как отдельные объекты (набор состояний, развертывание ...) с их отдельной службой, через которую эти одноранговые узлы будут доступны (но этот вид поражает цель использования ресурсов высокого уровня Kubernetes, которые позволяют репликацию)?

Спасибо


kubernetes peer stellar
person Bakir Jusufbegovic    schedule 23.09.2018    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Таким образом, у вас может быть один 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

Надеюсь, поможет!

person Rico    schedule 24.09.2018

arrow_upward
0
arrow_downward

Стоит отметить: основная сила Kube - управление масштабируемыми рабочими нагрузками идентичных модулей. Вот почему ReplicaSet существует в Kube API.

Узлы валидатора цепочки блоков не идентичны модулям. Они не анонимны; они идентифицируются своими общедоступными адресами, для которых требуются уникальные закрытые ключи.

Узлы блокчейна, которые служат узлами RPC, в этом смысле проще; они могут быть реплицированы, а запросы RPC могут быть циклически распределены между узлами.

Есть смысл использовать Kube для сетей блокчейнов; но если кажется, что развертывание валидаторов (и загрузочных узлов) идет не так, как есть, то это потому, что оно не совсем вписывается в модель ReplicaSet.

person Igor Lilic    schedule 27.12.2019