Есть ли способ сделать балансировку нагрузки между модулем в нескольких узлах?

Question

У меня есть кластер kubernetes, развернутый с помощью rke witch, который состоит из 3 узлов на 3 разных серверах, и на этих серверах есть 1 модуль, на котором запущен yatsukino / healthereum, что является личной модификацией ethereum / client-go: stable.Проблема в том, что я не понимаю, как добавить внешний ip для отправки запроса на модули, которые

Мои модули могут находиться в 3 состояниях:

1. они синхронизируют эфириумblockchain
2. они перезапустились из-за проблемы с синхронизацией
3. они синхронизированы и все в порядке

Я не хочу, чтобы мой балансировщик нагрузки передавал запросы на 2В первых состояниях только третий пункт рассматривает мой модуль как обновленный.

Я искал в документе kubernetes, но (возможно, из-за неправильного понимания) я нахожу балансировку нагрузки только для модулей внутри уникального узла.

Вот мой файл развертывания:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: goerli
  name: goerli-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: goerli
  template:
    metadata:
      labels:
        app: goerli
    spec:
      containers:
        - image: yatsukino/healthereum
          name: goerli-geth
          args: ["--goerli", "--datadir", "/app", "--ipcpath", "/root/.ethereum/geth.ipc"]
          env:
          - name: LASTBLOCK
            value: "0"
          - name: FAILCOUNTER
            value: "0"
          ports:
          - containerPort: 30303
            name: geth
          - containerPort: 8545
            name: console
          livenessProbe:
            exec:
              command:
              - /bin/sh
              - /app/health.sh
            initialDelaySeconds: 20
            periodSeconds: 60
          volumeMounts:
          - name: app
            mountPath: /app
      initContainers: 
      - name: healthcheck
        image: ethereum/client-go:stable
        command: ["/bin/sh", "-c", "wget -O /app/health.sh http://my-bash-script && chmod 544 /app/health.sh"]
        volumeMounts:
        - name: app
          mountPath: "/app"
      restartPolicy: Always
      volumes:
      - name: app
        hostPath:
          path: /app/

Answer 1

Ответы выше объясняют понятия, но о ваших вопросах о сервисах и внешних ip;вы должны объявить службу, например;

apiVersion: v1
kind: Service
metadata:
  name: goerli
spec:
  selector:
    app: goerli
  ports:
  - port: 8545
  type: LoadBalancer

type: LoadBalancer назначит внешний адрес для публичного облака или, если вы используете что-то вроде metallb .Проверьте свой адрес с kubectl get svc goerli.Если внешний адрес находится в состоянии ожидания, у вас возникла проблема ...

Если это ваша собственная настройка, вы можете использовать externalIPs для назначения собственного внешнего ip;

apiVersion: v1
kind: Service
metadata:
  name: goerli
spec:
  selector:
    app: goerli
  ports:
  - port: 8545
  externalIPs:
  - 222.0.0.30

externalIPs можно использовать извне кластера, но вы должны направить трафик на любой узел, например;

ip route add 222.0.0.30/32 \
  nexthop via 192.168.0.1 \
  nexthop via 192.168.0.2 \
  nexthop via 192.168.0.3

Предполагая, что у ваших узлов k8s есть ip 192.168.0.x.Это настроит маршруты ECMP к вашим узлам.Когда вы делаете запрос из-за пределов кластера на 222.0.0.30:8545, k8s будет балансировать нагрузку между вашими ready POD.

Answer 2

Для балансировки нагрузки и экспонирования ваших капсул вы можете использовать https://kubernetes.io/docs/concepts/services-networking/service/

, а для проверки готовности капсулы вы можете настроить параметры жизнеспособности и готовности, как описано https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

для зондов вы можете рассмотреть exec-действия, такие как выполнение скрипта, который проверяет, что требуется, и возвращает 0 или 1 в зависимости от статуса.

Answer 3

Когда контейнер запускается, Kubernetes может быть настроен на ожидание настраиваемого количество времени, которое нужно пройти перед выполнением первой проверки готовности. После этого это периодически вызывает зонд и действует в зависимости от результата проверки готовности. Если Pod сообщает, что он не готов, он удален из службы. Если стручок становится готов снова, он снова добавлен. В отличие от тестов жизнеспособности, если контейнер не проходит проверку готовности, он не будет убит или перезапущен. Это важное различие между зондами живучести и готовности. Датчики жизнеспособности сохраняют капсулы здоровыми, убивая нездоровые контейнеры и заменяя они с новыми, здоровыми, тогда как датчики готовности удостоверяются, что только стручки, которые готовы обслуживать запросы, получать их. Это в основном необходимо во время контейнера запустить, но это также полезно после того, как контейнер некоторое время работал.

Я думаю, вы можете использовать зонд для своей цели