服务发现

本文档简要介绍了基于 Kubernetes DNS 的服务发现以及如何将其与 Kf 搭配使用。

何时使用 Kubernetes 服务发现和 Kf

Kubernetes 服务发现可供需要以一致的方式查找支持性服务的应用使用,无论应用部署在何处。例如,团队可能希望在其配置中采用始终指向本地 SMTP 网关的通用 URI,以便将代码与运行它的环境分离开来。

服务发现可通过以下方式帮助应用团队:

  • 减少每个环境的配置数量。
  • 分离客户端应用与服务器应用。
  • 允许应用移植到新环境。

在以下情况下,您可以使用 Kubernetes 服务发现:

  • 应用使用其容器的 DNS 配置来解析主机。
  • 应用与其后备服务部署在同一 Kubernetes 集群或命名空间中。
  • 支持性服务具有关联的 Kubernetes 服务。Kf 为每个应用创建这些服务。
  • Kubernetes NetworkPolicy 允许应用与其需要通信的 Kubernetes 服务之间的流量。Kf 在每个 Kf 空间中创建这些政策。

在以下情况下,不应使用 Kubernetes 服务发现:

  • 应用需要在多个集群之间故障切换。
  • 您替换了应用使用的 DNS 解析器。
  • 应用需要特定类型的负载平衡。

Kubernetes 服务发现的工作原理

Kubernetes 服务发现的工作原理是修改 Kubernetes 节点上运行的容器的 DNS 配置。当应用查找非限定的域名时,本地 DNS 解析器会首先尝试解析本地集群中的名称。

没有多个部分的网域将根据容器命名空间中的 Kubernetes 服务的名称进行解析。每个 Kf 应用都会创建一个同名的 Kubernetes 服务。如果在同一个 Kf 空间中部署了两个 Kf 应用 pingpong,则 ping 可以使用网址 http://pong 将流量发送到其他服务。

只有一个点号的网域将根据 Kubernetes 命名空间中具有与点号后标签相同名称的 Kubernetes 服务进行解析。例如,如果一个 PostgreSQL 数据库在 database 命名空间中有一个 customers 服务,则另一个命名空间中的应用可以使用 postgres://customers.database 来解析该服务。

如何将服务发现与 Kf 搭配使用

任何 Kf 应用都可以使用基于 Kubernetes DNS 的服务发现。每个 Kf 应用都会创建一个同名的 Kubernetes 服务,每个 Kf 空间都会创建一个同名的 Kubernetes 命名空间。

  • 使用 protocol://app-name 引用当前空间中的 Kf 应用。
  • 使用 protocol://app-name.space-name 引用其他空间中的 Kf 应用。
  • 使用 protocol://app-name:port 引用当前空间中侦听自定义端口的 Kf 应用。
  • 使用 protocol://app-name.space-name:port 引用其他空间中侦听自定义端口的 Kf 应用。

最佳做法

应对要成为基于 DNS 的服务发现的目标的应用进行频繁的健康检查,以确保在接受连接的主机池中快速添加和移除这些应用。

使用基于 DNS 的服务发现的应用不应缓存已解析服务的 IP 地址,因为它们不一定是稳定的。

如果集群外存在特定于环境的服务,如果您设置了 ExternalName Kubernetes 服务,则可以使用 Kubernetes DNS 解析这些服务。这些 Kubernetes 服务提供相同的解析功能,但返回 CNAME 记录以将请求重定向到外部机构。

与 Eureka 比较

Eureka 是由 Netflix 创建的开源客户端负载平衡器。它通常用作 Spring Cloud 服务 service broker 的一部分。Eureka 构建为区域级负载平衡器和服务发现机制,用于在导致不稳定的 IP 地址的工作负载频繁中断的环境中运行的服务。

Eureka 设计为客户端/服务器模型。客户端将自己注册到服务器,指示它们要关联的名称,并定期发送服务器检测信号。服务器允许所有连接的客户端解析名称。

通常,您应该使用 Kubernetes DNS 而不是 Eureka in Kubernetes,原因如下:

  • DNS 可用于所有编程语言和应用,并且不需要使用库。
  • 系统会重复使用应用的现有健康检查,减少错误组合。
  • Kubernetes 管理 DNS 服务器,允许您依赖较少的依赖项。
  • Kubernetes DNS 遵循与 Kubernetes 的其余部分相同的政策和 RBAC 限制条件。

在少数情况下,部署 Eureka 服务器会比较有利:

  • 您需要在 Kubernetes 应用和基于虚拟机的应用中使用服务发现。
  • 您需要基于客户端的负载平衡。
  • 您需要独立的健康检查。

后续步骤