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

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

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

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

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

Спасибо

Источник

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

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

Источник

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

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

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

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

Источник
Другие вопросы по тегам