深入理解 Kubernetes 集群内服务通信机制

深入了解支持服务间通信的 3 个原生 K8s 对象：ClusterIP Service、DNS 和 Kube-Proxy。

 

 

 

 

据 Kubernetes 网络模型：

1. 集群中的每个 pod 都有自己唯一的集群范围 IP 地址
2. 所有 pod 都可以与集群内的每个 pod 通信
3. 通信在没有 NAT 的情况下发生，这意味着目标 pod 可以看到源 pod 的真实 IP 地址。Kubernetes 认为容器网络或在其上运行的应用程序是可信的，不需要在网络级别进行身份验证。

 

CoreDNS ~ 集群内的服务发现

 

 

现在服务 B 已经获得了一个持久的 IP 地址，服务 A 仍然需要知道这个 IP 地址是什么，然后才能与服务 B 通信。

Kubernetes 支持使用 CoreDNS 进行名称解析。服务 A 应该知道它需要与之通信的 ClusterIP 的名称（和端口）

1. CoreDNS 扫描集群，每当创建 ClusterIP 服务时，它的条目就会添加到 DNS 服务器（如果已配置，它还会为每个 pod 添加一个条目，但它与服务到服务的通信无关）。
2. 接下来，CoreDNS 将自己暴露为 cluster IP 服务（默认称为 kube-dns），并且该服务被配置为 pod 中的 nameserver。
3. 发起请求的 Pod 从 DNS 获取 ClusterIP 服务的 IP 地址，然后可以使用 IP 地址和端口发起请求。

Kube-proxy 打通 Service 和后端 Pod 之间（DNAT）

到目前为止，从本文来看，似乎是 ClusterIP 服务将请求调用转发到后端 Pod。但实际上，它是由 Kube-proxy 完成的。

Kube-proxy 在每个节点上运行，并监视 Service 及其选择的 Pod（实际上是 Endpoint 对象）。

1. 当节点上运行的 pod 向 ClusterIP 服务发出请求时，kube-proxy 会拦截它。
2. 通过查看目的 IP 地址和端口，可以识别目的 ClusterIP 服务。并将此请求的目的地替换为实际 Pod 所在的端点地址。

 

如何协同工作？

 

 ClusterIP Service、CoreDNS、客户端 Pod、Kube-Proxy、EndPoint的交互

1. 目标的 ClusterIP 服务在 CoreDNS 中注册
2. DNS 解析：每个 pod 都有一个 resolve.conf 文件，其中包含 CoreDNS 服务的 IP 地址，pod 执行 DNS 查找。
3. Pod 使用它从 DNS 收到的 IP 地址和它已经知道的端口来调用 clusterIP 服务。
4. 目标地址转换：Kube-proxy 将目标 IP 地址更新为服务 B 的 Pod 可用的地址。

转:https://mp.weixin.qq.com/s/d90NObAhc3193hLZHGIq5A