理解 Kubernetes 集群内服务通信

2022-08-04 15:57:51

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

在进入 Kubernetes 生态系统之前，快速了解一下传统的服务到服务通信：通信是通过 IP 地址进行的，因此为了让服务 A 调用服务 B，一种方法是为服务 B 分配一个静态 IP 地址。现在，服务 A 已经知道该 IP 地址（这在处理极少数服务时可能会起作用）或服务 B 使用域名注册自己，并且服务 A 通过 DNS 查找获取服务 B 的联系地址。

Kubernetes 网络模型

现在在 Kubernetes 集群中，我们拥有构成集群管理组件和一组工作机器（称为节点）的控制平面。这些节点托管 Pod，这些 Pod 将后端微服务作为容器化服务运行。

根据 Kubernetes 网络模型：

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

ClusterIP 服务 ~ 基于 Pod 的抽象

既然集群中的每个 pod 都有自己的 IP 地址，那么一个 pod 与另一个 pod 通信应该很容易吧？

不，因为 Pod 是易变的，每次创建 pod 时都会获得一个新的 IP 地址。所以客户端服务必须以某种方式切换到下一个可用的 pod。

Pod 直接相互交谈的问题是另一个目标 Pod 的短暂性（随时可能销毁），其次是发现新 Pod IP 地址。

因此 Kubernetes 可以在一组 Pod 之上创建一个层，该层可以为该组提供单个 IP 地址并可以提供基本的负载平衡。

通过持久 IP 地址上的 ClusterIP 服务公开的 Pod，客户端与服务对话，而不是直接与 Pod 对话。

这种抽象是由 Kubernetes 中一个名为ClusterIP service的服务对象提供的。它在多个节点上产生，从而在集群中创建单个服务。它可以接收任何端口上的请求并将其转发到 pod 上的任何端口。

因此，当应用服务 A 需要与服务 B 对话时，它会调用服务 B 对象的 ClusterIP 服务，而不是运行该服务的单个 pod。

ClusterIP 使用 Kubernetes 中标签和选择器的标准模式来不断扫描匹配选择标准的 pod。Pod 有标签，服务有选择器来查找标签。使用它，可以进行基本的流量拆分，其中新旧版本的微服务在同一个 clusterIP 服务后共存。

CoreDNS ~ 集群内的服务发现

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

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

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

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

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

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