Openshift/OCP-> 无法解析同一命名空间中的主机名。服务正在映射到不可解析的 POD 名称答案

【问题标题】：Openshift/OCP-> not able to resolve the hostname within same namespace. Service is mapping to the POD name which is not resolvableOpenshift/OCP-> 无法解析同一命名空间中的主机名。服务正在映射到不可解析的 POD 名称
【发布时间】：2020-11-23 23:20:54
【问题描述】：

我是 Kubernetes/OCP 世界的新手，我将我的应用程序部署到 OCP 命名空间并尝试连接到同样位于同一命名空间中的 gemfire 服务器。为了访问，我创建了一个ClusterIPService：ocp-gemfire。此服务公开10334 和40404 端口，并且相同的端口在下划线容器中公开。我的期望是，当我通过此服务时，它应该从我的应用程序连接如下：

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

但实际情况是，它映射到下划线Pod 名称而不是 IP。我能够从两个端口上的应用程序远程登录 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

【问题讨论】：

标签： kubernetes open-closed-principle

【解决方案1】：

如你所见here:

通常一个 pod 具有以下 DNS 解析：

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

例如，如果 default 命名空间中的 pod 具有 IP 地址 172.17.0.3，你的集群的域名是cluster.local，那么Pod就有了DNS名称：

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

由服务公开的 Deployment 或 DaemonSet 创建的任何 pod 有以下可用的 DNS 解析：

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

因此，您通过DNS 解析Pod 名称的尝试从一开始就注定要失败。

您可能想看看my other answer，它涉及非常相似的主题。

首先，您的应用程序根本不应该引用您的Pods 名称。对于与您的Pods 的连接，它应该只使用Service。它可能是一个简短的形式。 Service 名称部署在与 Pods 相同的命名空间时就足够了，如果它位于与 Pods 不同的命名空间中，则 FQDN。

也许我这里有些不太明白...

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

但上面的错误消息看起来像是来自您的应用程序。那么，当您从另一个 Pod 远程登录到 Service 名称时，究竟会发生什么，它是 FQDN 还是集群 IP？您应该被重定向到您的Pods 之一。您是否收到过您的Pod 名称无法解析的类似消息？

我很确定您的 Service 正确映射到您的 Pods，因为它在后台使用了它们的标签。因此，即使 Pod 被销毁，另一个会被创建并且它可以在完全不同的 IP 和名称下使用，Service 会负责更新端点列表，因此它可以始终将您的流量引导到选定的 Pods（由Service 定义中的选择器，它使用那些 Pods 标签）。

就您的Service 定义而言，它看起来是正确的，并且在任何情况下都不应该简单地映射到您的Pod 名称，因为它与kubernetes 本身的设计相矛盾，对吧？如果 Pod 名称无法根据定义解析，那么 Service 作为解决方案的一部分使用无法解析的 Pod 名称会很奇怪。

我认为来自您的应用程序的错误消息显示的内容有所不同，就好像您的 Pod 正在通过其名称向该应用程序做广告，而您的应用程序试图通过解析此名称来连接它们，这当然是做不到的。

简单的 Google 搜索短语 AutoConnectionSource discovered new locators 就足以确定它是 process typical to gemfire，因此与 Kubernetes/Openshift 没有直接关系。所以我们可以在这里看到：

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

由于某种原因，此发现使用简单的 Pod 名称并尝试使用 <pod-name>:port 连接字符串连接到它们，这当然是不可能的。

【讨论】：