Emissary Ingress 中 Host 与 Mapping 配置问题解析

问题背景

在使用 Emissary Ingress（原 Ambassador API Gateway）时，很多用户会遇到路由配置不生效的问题，特别是在 AWS EKS 环境中使用 NLB 负载均衡器时。一个典型的表现是访问配置的后端服务时返回 404 错误，而日志显示"no route match"。

核心问题分析

这个问题通常源于 Host 资源与 Mapping 资源之间的配置不匹配。在 Emissary Ingress 中，Host 资源定义了如何处理进入的请求，而 Mapping 资源则定义了如何将请求路由到后端服务。当两者配置不一致时，就会出现路由无法匹配的情况。

配置详解

典型错误配置

很多用户会像下面这样配置 Host 资源：

apiVersion: getambassador.io/v3alpha1
kind: Host
metadata:
  name: emissary
spec:
  hostname: "*"
  selector:
    matchLabels:
      hostname: wildcard

同时配置 Mapping 资源：

apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: quote-backend
spec:
  hostname: "*"
  prefix: /backend/
  service: quote

问题根源

这种配置的问题在于 Host 资源中使用了 selector 选择器，但 Mapping 资源没有相应的标签。Emissary Ingress 在这种情况下会严格执行标签匹配，导致 Mapping 无法被正确关联。

解决方案

方案一：简化 Host 配置

最简单的解决方案是移除 Host 资源中的 selector 部分，因为已经使用了通配符 hostname：

apiVersion: getambassador.io/v3alpha1
kind: Host
metadata:
  name: emissary
spec:
  hostname: "*"

方案二：保持选择器并添加标签

如果确实需要使用选择器，则需要在 Mapping 资源中添加匹配的标签：

apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: quote-backend
  labels:
    hostname: wildcard
spec:
  hostname: "*"
  prefix: /backend/
  service: quote

最佳实践建议

1. 优先使用简单配置：除非有特殊需求，否则建议使用简单的 Host 配置，避免不必要的选择器。

2. 明确命名空间：确保 Host 和 Mapping 资源位于相同的命名空间，或者正确配置 hostBinding。

3. 日志分析：当遇到路由问题时，检查 Emissary Ingress 的调试日志，关注"no route match"相关条目。

4. 逐步验证：先配置最基本的 Host 和 Mapping，验证通过后再逐步添加其他功能。

总结

Emissary Ingress 的路由配置需要特别注意 Host 和 Mapping 资源之间的关联性。选择器的使用需要谨慎，不必要的情况下建议简化配置。通过理解这些核心概念，可以避免常见的路由匹配问题，构建稳定可靠的 API 网关服务。