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

Question

任何人都可以让我知道我们如何通过 kubernetes 集群中的另一个 pod 访问部署在一个 pod 上的服务？

例子:

有一个 nginx 服务部署在 Node1 上(pod 名称为 nginx-12345)，另一个服务部署在 Node2 上(pod 名称为 service-23456)。现在，如果 'service' 出于某种原因想要与 'nginx' 通信，那么我们如何访问 'service-23456' pod 中的 'nginx'？

Answer 1

在 kubernetes 中访问服务的方式有很多种，你可以通过 NodePort 或 LoadBalancer 暴露你的服务，并在集群外访问。

参见how to access the services的官方文档.

Kubernetes 官方文档指出:

Some clusters may allow you to ssh to a node in the cluster. From there you may be able to access cluster services. This is a non-standard method, and will work on some clusters but not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.

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

编辑:

一旦该服务部署在您的集群中，您应该能够使用其名称联系该服务，并且 Kube-DNS将回答正确 ClusterIP与您的最后一个 pod 通话。 ClusterIP 由 kube-proxy 在 Workers 上创建的 IPTables 规则管理，这些规则将您的请求 NAT 到最终容器的 IP。

Kube-DNS 命名约定是 service.namespace.svc.cluster-domain.tld并且默认集群域是 cluster.local .

例如，如果您想联系名为 mysql 的服务在 db来自任何命名空间的命名空间，您可以简单地联系 mysql.db.svc.cluster.local .

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

编辑2:
ubuntu 中的 dns 解析存在一些已知问题，Kubernetes 官方文档指出

Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (systemd-resolved). Systemd-resolved moves and replaces /etc/resolv.conf with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers. This can be fixed manually by using kubelet’s --resolv-conf flag to point to the correct resolv.conf (With systemd-resolved, this is /run/systemd/resolve/resolv.conf). kubeadm 1.11 automatically detects systemd-resolved, and adjusts the kubelet flags accordingly.