从Ambassador迁移至AKS的Azure应用网关Ingress Controller功能匹配咨询

下面是你当前Ambassador功能对应的AGIC实现方式，以及所需的配置和工具说明：

1. 微服务Ingress路由 #

AGIC的核心功能就是实现K8s服务的Ingress路由，直接使用标准Kubernetes Ingress资源即可。只需在Ingress中指定kubernetes.io/ingress.class: azure/application-gateway注解，AGIC会自动将路由规则同步到关联的Azure应用网关，将外部流量转发到对应后端Service。

2. 在配置中定义路由 #

• 基础路由：直接通过Ingress的spec.rules字段定义域名、路径和后端Service，支持精确匹配、前缀匹配等路径规则。
• 路径重写/高级路由：使用AGIC专属注解azure.com/backend-path-prefix实现路径重写；如果需要基于请求头、查询参数的路由，可以通过应用网关的路由规则配合AGIC的注解azure.com/routing-rule-type来配置，所有规则都会通过Ingress资源同步到网关。

3. 跨命名空间API调用路由 #

AGIC原生支持跨命名空间Service引用，无需额外插件。只需在Ingress的backend字段中明确指定目标Service的命名空间，格式如下：

backend:
  service:
    name: target-service
    namespace: target-namespace
    port:
      number: 80

注意确保Ingress所在命名空间的ServiceAccount拥有访问目标命名空间Service的RBAC权限（默认集群角色已包含该权限，若自定义RBAC需补充）。

4. 非公开路由认证校验 #

AGIC结合Azure应用网关的认证能力实现，主要通过注解配置：

• 标记需要认证的路由：给Ingress或特定路径添加azure.com/use-auth: "true"注解。
• 配置认证规则：使用azure.com/auth-url指定Keycloak的认证端点，azure.com/auth-client-id、azure.com/auth-secret等注解配置Keycloak客户端信息，应用网关会自动拦截未认证请求，跳转到Keycloak登录页面或返回认证失败响应。

5. 请求认证Pod（对接Keycloak验证令牌） #

如果需要像Ambassador那样通过独立Pod验证请求头/URL参数中的令牌，有两种方案：

1. 应用网关JWT验证（无需额外Pod）：通过AGIC注解直接配置Keycloak的JWT验证，比如azure.com/jwt-issuer指定Keycloak发行者URL，azure.com/jwks-uri指定JWKS密钥端点，应用网关会自动校验请求中的令牌有效性，无需额外认证Pod。
2. 自定义认证Pod前置：若必须使用独立认证Pod，可将认证Pod部署为K8s Service，在Ingress中配置路径规则，先将请求转发到认证Pod，验证通过后再转发到业务Service。AGIC支持这种链式路由，只需在Ingress中配置对应的路径和后端即可。

工具依赖说明 #

• 核心功能（路由、跨命名空间访问）仅需AGIC+标准Ingress资源，无需额外插件。
• 认证功能：若使用应用网关原生认证，无需额外工具；若需复杂认证逻辑（如自定义令牌校验逻辑），可搭配Azure API Management（APIM），将APIM作为流量入口，先完成认证再转发到AKS服务。
• RBAC配置：跨命名空间访问需确保Ingress所在ServiceAccount有足够权限（默认AGIC的ServiceAccount已配置集群级权限，若自定义需调整）。

内容的提问来源于stack exchange，提问作者Jananath Banuka