Question

尝试在ECS群集上应用修改时遇到麻烦。环境的特殊性：

集群有两项服务：蓝色和绿色。
当前，这两个服务都与应用程序负载平衡器相关联暴露在互联网上。

我要做什么：添加另一个ALB（在本例中为内部ALB），以接收来自VPC中专用子网的相同服务（相同容器，相同端口）的请求。尝试应用这些修改时，出现以下错误：

CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename [ClusterName|ServiceName] and update the stack again.

我正在使用yml文件描述这些新实体。值得一提的是，新的负载均衡器，其侦听器和目标组已成功创建（即使目标组未检测到EC2实例）。将LB添加到ECS服务时会出现问题。这正常吗？同一端口和相同容器名称的相同ECS服务是否可以有2个LB？是否有一种解决方法可以在不重命名群集的情况下执行此操作？

编辑：我尝试创建一个带有2个负载均衡器的新ECS服务，但出现以下错误（更为具体）：

load balancers can have at most 1 items

因此，不能，ECS服务不能与多个ALB关联。剩下的问题是：除了为私有子网创建新的ECS服务以外，还有其他解决方法吗？

谢谢。

Answer 1

2019年7月30日，Amazon ECS发布了支持在ECS服务中使用多个负载均衡器/目标组的支持。来自他们的What's New blog post：

Amazon ECS服务现在支持多个负载均衡器目标组

您现在可以将多个目标组附加到您的Amazon ECS服务   在Amazon EC2或AWS Fargate上运行的文件。目标群体   用于将请求路由到一个或多个注册目标，当   使用负载平衡器。将多个目标群体附加到您的   服务使您可以简化基础架构代码，降低成本并   提高您的ECS服务的可管理性。

如文档中所述，这将启用不同的设置，包括与您在问题中提到的内部和外部负载平衡器集成。来自docs（重点是我）：

示例：为内部和外部使用单独的负载均衡器   交通。

在以下用例中，服务使用两个单独的负载   平衡器，一个用于内部流量，第二个用于面向互联网   同一集装箱和港口的流量。

"loadBalancers":[
   //Internal ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"nginx",
      "containerPort":8080
   },
   //Internet-facing ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"nginx",
      "containerPort":8080
   }
]

AWS容器服务公共路线图中的相关github问题（现已关闭）在此处找到：

Answer 2

虽然我来晚了，但是7月启动的功能可以为正在寻找它的人们解决这个问题。

参考：https://aws.amazon.com/about-aws/whats-new/2019/07/amazon-ecs-services-now-support-multiple-load-balancer-target-groups/

现在，您可以为每个ECS服务附加多个目标组。这个允许您维护一个可以服务流量的ECS服务来自内部和外部负载平衡器，并支持多个需要暴露更多信息的基于路径的路由规则和应用程序多于一个端口。

Answer 3

正如您正确观察到的那样，ECS每个服务最多只能有1个负载均衡器。 [1]
另一个SO线程声明以下内容：[2]

Elastic Load Balancer不可能同时具有公共IP地址和私有IP地址。是一个或另一个，但不是两个。

如果您希望ELB具有私有IP地址，则它不能监听来自互联网的请求。

这意味着，如果您的私有子网中的实例已经过NAT，因此可以访问Internet，则可以对其使用单个公共负载平衡器。但是，由于可能并非如此，您可以使用两个负载均衡器-每个负载均衡器都由各自的ECS服务支持。我知道那不是你想要的...

因此，在寻找解决方法时，我发现了以下在某些情况下可能有效的解决方案（请参阅“先决条件”）：

先决条件

您不需要负载均衡来自公共子网的内部流量，而是可以直接访问任务（实际上，负载均衡由Route53提供）。
您正在使用FARGATE启动类型。
您使用awsvpc，网桥或主机网络模式。
您不使用经典负载均衡器。

解决方案

将服务发现用于ECS。 [3]
它是将AWS Cloud Map集成到AWS ECS中。

您可以像以前一样将公共负载均衡器连接到ECS服务。此外，还为服务设置了服务发现名称空间。
ECS将任务的专用IP写入DNS名称空间。然后可以通过私有子网中的实例查询DNS名称空间。

我认为此解决方案应该有效，因为文档明确声明：

您可以为负载均衡器后面的ECS服务配置服务发现，但是服务发现流量始终路由到任务，而不是负载均衡器。 [3]

如果要设置此方案，请注意以下几点：

只能在首次创建服务时配置服务发现。不支持更新现有服务以首次配置服务发现或更改当前配置。 [3]

参考文献

[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_limits.html（“每项服务的负载均衡器数量”）
[2] https://stackoverflow.com/a/36586238/10473469
[3] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html

Answer 4

我们最终决定提供2种服务：一种用于内部使用，另一种用于公共使用，每种服务都具有自己的负载平衡器（分别为内部和面向互联网）。 AWS的支持人员后来批准了此解决方案，他们说这是此案例的推荐解决方法。

具有两个负载均衡器的ECS服务用于同一端口：内部和面向互联网的

4 个答案:

先决条件

解决方案

参考文献