Openshift / OCP-> не может разрешить имя хоста в том же пространстве имен. Служба сопоставляется с именем POD, которое не разрешается - PullRequest
Новая
       18

Openshift / OCP-> не может разрешить имя хоста в том же пространстве имен. Служба сопоставляется с именем POD, которое не разрешается

0 голосов
/ 04 августа 2020

Я новичок в мире Kubernetes / OCP , развертываю свое приложение в пространстве имен OCP и пытаюсь подключиться к серверу gemfire , который также находится в том же пространстве имен. Для доступа я создал ClusterIP Service: ocp-gemfire. Эта служба предоставляет порты 10334 и 40404, и те же порты отображаются в подчеркнутом контейнере. Чего я ожидаю, когда я передам эту службу, она должна подключиться из моего приложения, как показано ниже: 

ocp-gemfire/xx.xx.xx.xx(Service IP):10334
ocp-gemfire/xx.xx.xx.xx(Service IP):40404

Но что происходит, это его отображение для подчеркивания Pod имени, а не IP. Я могу указать lnet IP или имя службы из приложения на обоих портах; однако это Pod имя не разрешимо.

Я не уверен, почему его сопоставление с Pod именем, а не IP-адресом? 

2020-08-03 16:55:20 INFO  - AutoConnectionSource discovered new locators [myapp-gemfire-1-9npl6:10334]
2020-08-03 16:55:20 WARN  - Could not connect to: myapp-gemfire-1-9npl6:40404
java.net.UnknownHostException: myapp-gemfire-1-9npl6

Моя служба: 

apiVersion: v1
kind: Service
metadata:
  labels:
    app: ${APPLICATION_NAME}-gemfire
  name: ${APPLICATION_NAME}-gemfire
  namespace: ${PROJECT_NAMESPACE}
spec:
  type: ClusterIP
  ports:
    - name: 10334-tcp
      port: 10334
      protocol: TCP
      targetPort: 10334
    - name: 40404-tcp 
      port: 40404
      protocol: TCP
      targetPort: 40404
  selector:
    app: ${APPLICATION_NAME}-gemfire
    deploymentconfig: ${APPLICATION_NAME}-gemfire

1 Ответ

0 голосов
/ 04 августа 2020

Как вы можете прочитать здесь :

Обычно модуль имеет следующее разрешение DNS:

pod-ip-address.my-namespace.pod.cluster-domain.example.

Например, если модуль в пространстве имен default имеет IP-адрес 172.17.0.3, а имя домена для вашего кластера - cluster.local, тогда модуль имеет DNS-имя:

172-17-0-3.default.pod.cluster.local.

Любые модули, созданные с помощью развертывания или DaemonSet, предоставляемого Сервисом, имеют следующее доступное разрешение DNS:

pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.

Итак, ваши попытки разрешить Pod имена через DNS обречены на провал с самого начала.

Возможно, вы захотите взглянуть на мой другой ответ , который касается очень похожих topi c.

Прежде всего, ваше приложение вообще не должно ссылаться на ваши Pods имена. Для связи с вашим Pods он должен использовать только Service. Это могло быть в краткой форме. Service name вполне достаточно, если он развернут в том же пространстве имен, что и Pods, из которого вы подключаетесь к нему, или FQDN, если он находится в другом пространстве имен, чем ваш Pods.

Возможно Я здесь кое-что не понимаю ... 

2020-08-03 16:55:20 INFO  - AutoConnectionSource discovered new locators [myapp-gemfire-1-9npl6:10334]
2020-08-03 16:55:20 WARN  - Could not connect to: myapp-gemfire-1-9npl6:40404
java.net.UnknownHostException: myapp-gemfire-1-9npl6

, но сообщение об ошибке выглядит так, как будто оно исходит от вашего приложения. Так что же на самом деле происходит, когда вы подключаетесь по telnet с другого имени Pod на Service, это полное доменное имя или IP-адрес кластера? Вы должны быть перенаправлены на один из ваших Pods. Получаете ли вы подобное сообщение о том, что ваше имя Pod не может быть разрешено?

Я почти уверен, что ваш Service правильно отображается на ваш Pods, поскольку он использует свои метки под капотом. Таким образом, даже если Pod уничтожается, создается другой, и он доступен под совершенно другим IP-адресом и именем, Service заботится об обновлении списка конечных точек, чтобы он всегда мог направить ваш трафик c на выбранный Pods ( выбирается селектором в определении Service, которое использует эти Pods метки).

Что касается вашего определения Service, оно выглядит правильно и не должно просто отображаться на ваш Pod имена ни при каких обстоятельствах, так как это противоречило бы самому дизайну кубернетов, верно? Если имена Pod не разрешаются по определению, было бы странно, что Service, являясь частью решения, использовало Pod имена, которые не разрешаются.

Сообщение об ошибке, которое, как я полагаю, исходит от вашего приложение показывает что-то другое, как если бы ваши модули рекламировали это приложение по их именам, а ваше приложение пытается подключиться к ним, разрешая это имя, что, конечно, невозможно.

Простой поиск в Google по фразе AutoConnectionSource discovered new locators достаточно, чтобы понять, что это процесс , типичный для gemfire , поэтому ничего напрямую не связано с Kubernetes / Openshift . Итак, как мы видим здесь: 

AutoConnectionSource discovered new locators [myapp-gemfire-1-9npl6:10334]

по какой-то причине это открытие использует простые Pod имена и пытается подключиться к ним с помощью строки подключения <pod-name>:port, что, конечно, невозможно.

...