多集群通信

Linkerd 可以以安全、对应用程序完全透明且独立于网络拓扑的方式跨集群边界连接 Kubernetes 服务。这种多集群功能旨在提供：

1. 统一的信任域。 在集群边界内和跨集群边界的每一步都验证源和目标工作负载的身份。
2. 单独的故障域。 一个集群的故障允许剩余的集群运行。
3. 支持异构网络。 由于集群可以跨越云、VPC、本地数据中心及其组合，Linkerd 不会引入除网关连接(gateway connectivity)之外的任何 L3/L4 要求。
4. 集群通信中的统一模型。 Linkerd 为集群内通信提供的可观测性、可靠性 和 安全特性也扩展到了跨集群通信。

就像集群内连接一样，Linkerd 的跨集群连接对应用程序代码是透明的。无论通信发生在集群内、数据中心或 VPC 内的集群之间，还是通过公共互联网，Linkerd 都会在集群之间建立连接，该连接在双方都使用 mTLS 进行加密和身份验证。

工作原理

Linkerd 的多集群支持通过在集群之间“镜像(mirroring)”服务信息来工作。由于远程服务被表示为 Kubernetes 服务，Linkerd 的完整可观察性、安全性和路由功能统一
适用于集群内和集群调用，应用程序不需要区分这些情况。

Linkerd 的多集群功能由两个组件实现：服务镜像(service mirror)和网关(gateway)。服务镜像(service mirror)组件监视目标集群中的服务更新，并在源集群上本地镜像这些服务更新。这提供了对目标集群的服务名称的可见性，以便应用程序可以直接寻址它们。多集群网关组件为目标集群提供了一种从源集群接收请求的方式。（这允许 Linkerd 支持 分层网络。）

安装这些组件后，可以将与标签选择器(label selector)匹配的 Kubernetes Service 资源导出到其他集群。

headless 服务

默认情况下，Linkerd 会将目标集群中所有导出的服务镜像为源集群中的 clusterIP 服务（它们将被分配一个虚拟 IP）。这也扩展到 headless services;导出的 headless 服务将在源集群中镜像为 clusterIP 服务。通常，当工作负载需要稳定的网络标识符或促进服务发现而不与 Kubernetes 的原生实现绑定时，会使用 headless 服务，这允许客户端实现自己的负载均衡或直接通过其 DNS 名称寻址 pod。在某些情况下，希望保留一些此功能，尤其是在使用需要它的 Kubernetes 对象时，例如 StatefulSet。

当将两个集群链接在一起时，Linkerd 的多集群扩展可以配置为支持 headless 服务。当该功能开启时，服务镜像(service mirror)组件将导出 headless 服务，而无需为其分配 IP。这允许客户端跨集群与特定的 pod（或主机）交谈。为了支持直接通信，在底层，服务镜像组件将为支持 headless 服务的每个主机创建一个端点镜像(endpoint mirror)。举例来说，如果在目标集群中有一个 StatefulSet 部署了两个副本，并且 StatefulSet 由一个 headless 服务支持，那么当服务将被导出时，源集群将创建一个 headless 镜像以及两个“端点镜像”，代表 StatefulSet 中的主机。

这种方法允许 Linkerd 保留 DNS 记录创建，并支持跨集群直接与 pod 通信。客户端还可以基于 headless 服务创建的 DNS 记录实现自己的负载均衡。主机名也在集群中保留，这意味着 DNS 名称（或 FQDN）的唯一区别是 headless 服务的镜像名称。为了导出为 headless 服务，需要命名支持服务的主机（例如，支持 StatefulSet，因为所有 pod 都有主机名，但不支持 Deployment，因为它们不允许 pod spec 中的任意主机名）。

准备好开始了吗？有关演练，请参阅多集群入门指南。

进一步阅读

• 多集群安装说明.
• 与 StatefulSets 的多集群通信.
• 多集群 Kubernetes 架构, 一篇博文，解释了 Linkerd 多集群实现背后的一些设计原理。
• 具有服务镜像的多集群 Kubernetes, 深入了解 Linkerd 多集群实现背后的一些架构决策。