Подключиться к Kubernetes mongo db в другом пространстве имен

Может ли кто-нибудь указать, как подключиться к экземпляру mongo db с помощью клиента mongo, используя либо клиент командной строки, либо из основных программ .net со строками подключения?

Мы создали образец кластера в digitalocean с пространством имен, скажем, mongodatabase.

Мы установили набор состояний mongo с 3 репликами. Мы можем успешно подключиться с помощью следующей команды kubectl --kubeconfig = configfile.yaml -n mongodatabase exec -ti mongo-0 mongo Но когда мы подключаемся из другого пространства имен или из пространства имен по умолчанию с модулем имена в формате ниже, это не работает.

 kubectl --kubeconfig=configfile.yaml  exec -ti mongo-0.mongo.mongodatabase.cluster.svc.local mongo

где mongo-0.mongo.mongodatabase.cluster.svc.local находится в pod-0.service_name.namespace.cluster.svc.local (также пробовал pod-0. statfulset_name.namespace.cluster.svc.local и pod-0.service_name.statefulsetname.namespace.cluster.svc.local) и т. д.,

Может ли кто-нибудь помочь с правильным именем DNS / строкой подключения, который будет использоваться при подключении к клиенту mongo в командной строке, а также из таких программ, как ядро ​​java / .net и т. Д.?

Также следует ли использовать здесь развертывание кубернетов вместо наборов состояний?


person Muthu    schedule 28.05.2019    source источник
comment
Могу я узнать, почему проголосовали за закрытие?   -  person Muthu    schedule 28.05.2019
comment
Вы вообще не используете kubectl exec для обычных подключений. Имя хоста, которое у вас есть, выглядит правдоподобным для обычного клиента Mongo.   -  person David Maze    schedule 28.05.2019


Ответы (4)


Вам нужно ссылаться на службу mongo по DNS с пространством имен. Итак, если ваша служба mongo mymongoapp и развернута в mymongonamespace, вы сможете получить к ней доступ как mymongoapp.mymongonamespace.

Для тестирования я использовал bitnami/mongodb докер-клиент. Следующее:

Изнутри mymongonamespace эта команда работает

$ kubectl config set-context --current --namespace=mymongonamespace
$ kubectl run mongodbclient --rm --tty -i --image bitnami/mongodb --command -- mongo --host mymongoapp

Но когда я переключился на пространство имен по умолчанию, это не сработало

$ kubectl config set-context --current --namespace=default
$ kubectl run mongodbclient --rm --tty -i --image bitnami/mongodb --command -- mongo --host mymongoapp

Затем квалификация хоста с пространством имен работает

$ kubectl run mongodbclient --rm --tty -i --image bitnami/mongodb --command -- mongo --host mymongoapp.mymongonamespace
person frankd    schedule 29.05.2019
comment
Это отличный ответ @frankd. Большое тебе спасибо. Я боролся с командой exec, которая выполняет команду внутри контейнера, поскольку мне приходилось создавать клиентский контейнер с помощью run. Наконец, приведенная ниже команда добилась этого .. kubectl run mongodbclient --rm --tty -i --image mongo --restart = Never --command - mongo --host mongo-0.mongo.default.svc.cluster.local Вышеупомянутое может получить доступ к монго из любого другого пространства имен - person Muthu; 30.05.2019

Вот как вы можете попасть внутрь стручка mongo-0

kubectl --kubeconfig=configfile.yaml  exec -ti mongo-0 sh
person P Ekambaram    schedule 28.05.2019
comment
true, это работает, если набор состояний создается в том же пространстве имен. как мне получить доступ, если он находится в другом пространстве имен? - person Muthu; 28.05.2019

Я думаю, вы ищете этот DNS для служб и модулей.

У вас может быть полное доменное имя (FQDN) для Services или для Pod .

Также ознакомьтесь с kubernetes: Сервис, расположенный в другом пространстве имен, как Я думаю, он даст вам ответ о том, как получить к нему доступ из другого пространства имен.

Пример мог бы выглядеть так:

apiVersion: v1
kind: Service
metadata:
  name: default-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
  - name: foo # Actually, no port is needed.
    port: 1234
    targetPort: 1234
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  hostname: busybox-1
  subdomain: default-subdomain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox2
  labels:
    name: busybox
spec:
  hostname: busybox-2
  subdomain: default-subdomain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox

Если существует автономная служба в том же пространстве имен, что и модуль, и с тем же именем, что и поддомен, сервер KubeDNS кластера также возвращает запись A для полного имени хоста модуля. Например, для модуля Pod с именем хоста, установленным на «busybox-1», и поддоменом, установленным на «default-subdomain», и безголовым сервисом с именем «default-subdomain» в том же пространстве имен, модуль будет видеть свое собственное полное доменное имя как «busybox-1.default-subdomain.my-namespace.svc.cluster.local». DNS обслуживает запись A для этого имени, указывающую на IP-адрес модуля. Оба модуля «busybox1» и «busybox2» могут иметь свои отдельные записи A.

Объект Endpoints может указывать hostname для любого адреса конечной точки вместе с ее IP.

Примечание. Поскольку записи A не создаются для имен модулей, для создания записи A требуется hostname. Pod без hostname, но с subdomain создаст только запись A для автономной службы (default-subdomain.my-namespace.svc.cluster.local), указывающую на IP-адрес Pod. Кроме того, Pod должен быть готов, чтобы иметь запись, если для службы не установлено значение publishNotReadyAddresses=True.

person Crou    schedule 29.05.2019

Ваш вопрос о Deployments vs StatefulSets должен быть другим вопросом. Но ответ в том, что StatefulSet используется, когда вы хотите кубернетов "стабильное постоянное хранилище". io.

Также с той же страницы «стабильный» является синонимом постоянства (повторного) планирования Pod ». Таким образом, в основном ваш экземпляр mongo поддерживается PeristentVolume, и вы хотите, чтобы том повторно подключился после перепланирования модуля.

person frankd    schedule 29.05.2019