AWS ALB加权路由，而Ingress规则出现在同一域中记录别名

问题描述

我有一个API，该API目前由我们主要CA下的子域提供. api.domain.com .该API当前由Nginx入口控制器提供，并且计划将其替换为另一个入口控制器(即大使)，并尽可能避免因停机而进行部署.由于我们使用的是AWS EKS，因此需要进行以下配置:

I have an API that's currently served by a subdomain under our main CA e.g. api.domain.com.This API is currently served by an Nginx ingress controller and the plan is to replace that with another ingress controller (namely Ambassador) and as much as possible avoid a deployment with downtime.Since we're using AWS EKS I have the following configured:

• 配置为指向Nginx安装的ALB
• 一个指向大使装置的单独目标群体
• 配置了加权路由的ALB侦听器可在安装之间进行轮循(其想法是随意增加/减少流量，并监督新的Ingress Controller对其进行管理)
• 指向负载均衡器(api.domain.com)的Route53记录集别名
通过Nginx公开的
• 女主角与上面的记录(api.domain.com)相同

由于入口是由Kubernetes内部DNS处理的，所以我希望LoadBalancer将流量无缝地定向到两个目标组(Nginx和Ambassador)，但是我得到的是它仅将流量定向到Ambassador目标组，而一个也被定义为Nginx Ingress规则的规则，它目前仅提供503 Service Unavailable-请注意，Nginx安装可通过其他dns映射进行访问，因此一切正常.

Since the ingress is handled by Kubernetes internal DNS what I was hoping was for the LoadBalancer to direct traffic seamlessly to both target groups (Nginx and Ambassador), but what I get is it's directing traffic only to the Ambassador target group, while the one defined also as an Nginx Ingress rule currently it just gives 503 Service Unavailable - note that the Nginx installation is reacheble through other dns mappings so everything works ok.

知道我在做什么错吗?整个想法是在LB级别而不是DNS级别进行加权路由，以避免DNS传播问题.

Any idea what I'm doing wrong? The whole idea was to do weighted routing at LB level and not DNS level to avoid DNS propagation issues.

推荐答案

如对我自己的问题的评论所述，为了使其正常工作并在同一AWS ALB下暴露多个Ingress控制器，您必须验证以下清单:

As written in the comment to my own issue, in order for this to work and to have multiple Ingress controllers exposed under the same AWS ALB you have to validate the following checklist:

假设是您已经在使用Nginx或另一个默认控制器，该默认控制器公开了通配符证书(如 *.sub-)下列出的 api.sub-domain.domain.com 的入口.domain.domain.com

Assumption is that you are already using Nginx or another default controller that has ingress exposed for api.sub-domain.domain.com listed under a wildcard certificate such as *.sub-domain.domain.com

1. 为所需域添加Route53别名记录，例如 api.sub-domain.domain.com
2. 添加指向端口&的目标组新的Ingress Controller的实例/实例组
3. 在ALB中，将目标组添加到现有侦听器规则中，并以所需的权重进行流量路由
4. (可选)您可能需要定义一个新规则，并指定Host头与别名记录相同
5. 更新侦听器规则
6. 刷新 api.sub-domain.domain.com 页，然后在您喜欢的浏览器的网络"部分中检查服务器类型.以我为例，它是在Envoy(大使使用的基础代理)和Nginx之间切换的(或者您可能会看到与Php 7相关的内容*.)

1. Add a Route53 Alias record for the desired domain e.g. api.sub-domain.domain.com
2. Add a target group pointing to the port & instances/instance groups of your new Ingress Controller
3. In the ALB add the target group to the existing listener rules with the desired weight for traffic routing
4. (Optional) You might need to define a new rule with Host header specified the same as for the alias record
5. Update the listener rules
6. Refresh the api.sub-domain.domain.com page and check the Networking section of your favorite browser for server type. In my case it was switching between Envoy(underlying proxy used by Ambassador) and Nginx (or you might see something related to Php 7.*)

要注意的错误:

• 503服务不可用-可能表明您没有配置侦听器规则，或者未正确配置它.如果确实是配置问题，请仔细检查响应头是否有任何提及ELB的头
• 504网关超时-您的目标组配置不正确，并且您配置的端口未定位到Ingress Controller
• dns_probe_finished_nxdomain-您的Route53记录配置不正确或根本没有定义，请确保为您的域和所需的子域配置了CNAME和A类型记录.

这篇关于AWS ALB加权路由，而Ingress规则出现在同一域中记录别名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！