DNS-записи для стручков в неготовом состоянии - PullRequest
0 голосов
/ 16 января 2020

Я пытаюсь создать простой кластер mon go набор реплик в kubernetes.

У меня есть StatefulSet экземпляров mongod, с

      livenessProbe:
        initialDelaySeconds: 60
        exec:
          command:
            - mongo
            - --eval
            - "db.adminCommand('ping')"
      readinessProbe:
        initialDelaySeconds: 60
        exec:
          command:
            - /usr/bin/mongo --quiet --eval 'rs.status()' | grep ok | cut -d ':' -f 2 | tr -dc '0-9' | awk '{ if($0=="0"){ exit 127 }else{ exit 0 } }'

, как вы можете видеть, Мой readinessProbe проверяет, работает ли mon go replicaSet правильно.

однако я получаю циклическую зависимость с (и существующим) отчетом кластера:

        "lastHeartbeatMessage" : "Error connecting to mongo-2.mongo:27017 :: caused by :: Could not find address for mongo-2.mongo:27017: SocketException: Host not found (authoritative)",

(где mon go -2 подвергался непрерывному обновлению).

, глядя дальше:

$ kubectl  run --generator=run-pod/v1 tmp-shell --rm -i --tty --image nicolaka/netshoot -- /bin/bash

bash-5.0# nslookup mongo-2.mongo
Server:     10.96.0.10
Address:    10.96.0.10#53

** server can't find mongo-2.mongo: NXDOMAIN

bash-5.0# nslookup mongo-0.mongo
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   mongo-0.mongo.cryoem-logbook-dev.svc.cluster.local
Address: 10.27.137.6

, поэтому вопрос заключается в том, существует ли способ заставить kubernetes всегда сохранять запись DNS для пн go стручки, чтобы всегда присутствовать? похоже, что у меня есть ситуация с курицей и яйцом, когда, если весь модуль не прошел проверку готовности и живучести, запись dns не создается, и, следовательно, другие экземпляры mongod не смогут получить к ней доступ.

Ответы [ 2 ]

1 голос
/ 28 января 2020

В итоге я просто включил ClusterIP Service для каждого из экземпляров набора состояний с selector для , специфицирующим c экземпляр :

ie

apiVersion: v1
kind: Service
metadata:
  name: mongo-0
spec:
  clusterIP: 10.101.41.87
  ports:
  - port: 27017
    protocol: TCP
    targetPort: 27017
  selector:
    role: mongo
    statefulset.kubernetes.io/pod-name: mongo-0
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

и повторите для других sts с. ключ здесь - селектор:

statefulset.kubernetes.io/pod-name: mongo-0
0 голосов
/ 16 января 2020

Я полагаю, вы неверно истолковали ошибку.

Не удалось найти адрес для mon go -2.mon go: 27017 : SocketException: Хост не найден (авторитетно) "

Модуль создается с подключенным IP-адресом. Затем он регистрируется в DNS:

Pod-0 имеет IP-адрес 10.0.0.10, а теперь его полное доменное имя равно Pod-0.servicename.namespace.sv c .cluster.local

Pod-1 имеет IP 10.0.0.11 и теперь его полное доменное имя равно Pod-1.servicename.namespace.sv c .cluster.local

Pod-2 имеет IP 10.0.0.12 и теперь его полное доменное имя равно Pod-2.servicename.namespace.sv c .cluster.local

Но DNS - это действующий сервис, IP-адреса назначаются динамически и не могут дублироваться. Поэтому, когда он получает запрос:

"Соедините меня с Pod-A.servicename.namespace.sv c .cluster.local "

Он пытается достичь зарегистрированного IP и если Pod отключен из-за непрерывного обновления , он будет считать, что модуль недоступен и вернет «Не удалось найти адрес (IP) для Pod-0.servicename» , пока модуль не будет снова подключен к сети или пока не истечет резервирование IP, и только после этого DNS Реестр будет перезапущен.

DNS не отбрасывает зарегистрированное DNS-имя, а только отвечает, что он в данный момент отключен.

Вы можете либо игнорировать ошибки во время прокрутки, либо переосмыслите ваш сценарий и попробуйте использовать внутреннюю среду js, как указано в комментариях, для непрерывного мониторинга состояния mon go.

EDIT:

  • При развертывании модулей из StatefulSet с N репликами они создаются последовательно в порядке {0..N-1}.
  • Когда модули удаляются, они завершаются в обратном порядке, начиная с {N-1..0}.
  • Это ожидаемое / желаемое поведение по умолчанию.
  • Таким образом, ожидается ошибка, так как rollUpdate делает модуль временно недоступным.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...