如何通过Kubernetes中的另一个Pod访问部署在一个Pod上的服务？

Question

谁能让我知道我们如何通过kubernetes集群中的另一个Pod来访问部署在一个Pod上的服务？

例：

有一个部署在Node1上的Nginx服务（以Pod名称为Nginx-12345）和另一个部署在Node2上的服务（以Pod名称为Service-23456）。现在，如果“服务”出于某种原因要与“ nginx”进行通信，那么我们如何在“ service-23456”窗格中访问“ nginx”？

Answer 1

有多种方法可以在kubernetes中访问该服务，您可以通过NodePort或LoadBalancer公开您的服务，并在集群外部访问它。

请参阅有关如何访问服务的官方文档。

Kubernetes官方文件指出：

某些群集可能允许您SSH到群集中的节点。从那里您可能能够访问群集服务。这是一种非标准的方法，将在某些群集上有效，但在其他群集上无效。浏览器和其他工具可能会也可能不会安装。群集DNS可能无法正常工作。

因此，直接从其他节点访问服务取决于您所使用的Kubernetes集群类型。

编辑：

将服务部署到您的群集中后，您应该能够使用其名称与服务联系，并Kube-DNS会以正确的答案与ClusterIP您的最终Pod对话。ClusterIP由kube-proxy在Worker上创建的IPTables规则控制，该规则将您的请求NAT到最终容器的IP。

Kube-DNS命名约定为service.namespace.svc.cluster-domain.tld，默认群集域为cluster.local。

例如，如果您想从任何名称空间联系mysql在db名称空间中调用的服务，则只需与对话即可mysql.db.svc.cluster.local。

如果这不起作用，那么集群中的kube-dns可能存在问题。希望这可以帮助。

EDIT2：Ubuntu中存在DNS解析的一些已知问题，Kubernetes官方文件指出

某些Linux发行版（例如Ubuntu）默认情况下使用本地DNS解析器（systemd解析）。Systemd-resolved移动并用存根文件替换/etc/resolv.conf，当在上游服务器中解析名称时，该文件可能导致致命的转发循环。可以通过使用kubelet的--resolv-conf标志来指向正确的resolv.conf（使用systemd-resolved，这是/run/systemd/resolve/resolv.conf）来手动修复。kubeadm 1.11自动检测systemd-resolved，并相应地调整kubelet标志。

Answer 2

您是否将部署公开为服务？如果是这样，只需通过它的 dns 名称访问它，例如http://nginx-1234 - 或者如果它位于不同的命名空间中：http://nginx-1234.default.svc（将“默认”更改为服务所在的命名空间in) 或http://nginx-1234.default.svc.cluster.local

现在，如果您没有公开服务，那么您可能应该这样做。您不需要将它暴露给外界，只需不要定义服务类型，它只会在您的集群内部可用。

如果因为某种原因不想暴露一个服务（想不出什么原因），可以到api服务器查询pod IP。您将需要提供用于身份验证的令牌，但这些令牌在 pod 中可用：

获取令牌：

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

调用api服务器：

curl https://kubernetes.default.svc/api/v1/namespaces/default/pods--silent \
     --header "Authorization: Bearer $TOKEN" --insecure

您可以通过添加?fieldSelector=spec.nodeName%3Dtargetnodename或类似（只需使用 json 路径）来优化您的查询。可以使用https://stedolan.github.io/jq/或任何其他 JSON 实用程序解析输出。