外部服务别名：ExternalName 与 ServiceEntry 对比

本文为 Jimmy Song 原创。转载请注明来源： https://jimmysong.io/blog/externalname-and-serviceentry/

查看本文大纲

随着 Kubernetes 不断演进，Istio 功能逐渐在 Kubernetes 中找到对应实现，如 Sidecar 容器、Gateway API 以及本文的主题 ExternalName。ExternalName 和 ServiceEntry 都能起到引入 Kubernetes 集群外部服务的作用，但是它们的功能和使用场景也有所区别，本文将为你详细解析。

ExternalName vs ServiceEntry

下表从多个方面对比了 ExternalName 和 ServiceEntry ：

特性/用例	ExternalName	ServiceEntry
流量控制	有限，仅支持 TCP 和 UDP	更灵活，支持 TCP、UDP、HTTP 等多种协议，可以指定端口、TLS 等选项
服务发现	适用于外部服务的简单别名	适用于描述网格内外服务，包括外部和内部服务的详细配置
配置复杂性	简单，适用于基本的服务发现需求	较复杂，适用于需要高级流量控制和详细配置的场景
TLS 支持	有限，较简单	更丰富的 TLS 支持，可以指定证书等详细选项
安全性	较基本，适用于简单的用例	更强大的安全性支持，可以定义 `subjectAltNames` 等选项
用途	适用于简单的外部服务别名	适用于复杂的流量管理和服务发现需求，尤其是在多协议和复杂网络拓扑中

使用场景

ExternalName 的使用情况：

简单的服务别名： 外部服务只需一个简单别名，无需复杂流量控制，可选用 ExternalName。
无详细流量控制需求： 不需要对服务流量进行详细控制，只需简单的服务别名访问，选用 ExternalName。

ServiceEntry 的使用情况：

复杂流量控制需求： 需要更复杂的流量控制，如指定协议、端口、TLS 选项等，选择 ServiceEntry。
描述网格内外服务： 需要描述网格内外服务，包括外部和内部服务的详细配置，ServiceEntry 更适合。
对服务详细属性有要求： 需要为服务定义特殊属性，如 subjectAltNames 等，需使用 ServiceEntry。

在 Istio 中使用 ExternalName 可能遇到的问题

在 Istio 1.20 以前，网格内存在 ExternalName 类型的 Service 时，若该 Service 的端口与其他外部服务的端口重叠，流量可能错误路由到该 ExternalName Service。该问题已在 Istio 1.20 版本中解决，详见 Better support ExternalName #37331。

总结

在服务网格的选择中，ExternalName 和 ServiceEntry 分别提供了简单的服务别名和更复杂的流量管理与服务发现选项。ExternalName 适用于简单的外部服务别名，而 ServiceEntry 在处理复杂流量控制和网格内外服务时更具优势。在实际应用中，根据具体需求和配置的复杂性权衡，灵活选择合适的机制。随着 Istio 和 Kubernetes 的不断演进，这些功能的使用方式可能会受到影响，因此保持关注相关社区的更新和最佳实践是保持系统健康和高效运行的关键。选择合适的服务网格组件将有助于构建可靠、安全且高度可扩展的微服务架构。