我希望这是有意义的。
我们目前通过CloudFormation脚本在ECS中部署我们的微服务，使用我们填写每个微服务的参数化cloudform模板。我们使用配置了多个/path规则的单个ALB，其中每个规则针对一个微服务。所以监听器规则看起来像
api.company.com -> alb-microservices/default -> default-target-group
/microservice1/* -> microservice1-target-group
/microservice2/* -> microservice2-target-group
所以当我们的应用程序发送一个RESTful API调用到api.company.com/microservice1/some_path/...时，它会转到microservice1等。
我们通过CloudFormation资源
创建每个监听器规则AlbListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Condition: UseListenerRule
Properties:
ListenerArn:
Fn::ImportValue:
!Sub "${ECSClusterStackNameParameter}-ListenerArn"
Actions:
-
Type: forward
TargetGroupArn: !Ref AlbTargetGroup
Conditions:
-
Field: path-pattern
Values: [ !Ref LoadBalancerPathCondition ]
Priority: !Ref ListenerRulePriority
有了这个，我们可以在构建微服务时向ALB添加路径。每个微服务都有对应的"listenerrulepriority";我们在飞行中计算的数字。有意义吗?我理解上面的ALB和Kubernetes入口资源之间的1:1对应关系，我想对微服务入口进行参数化。Yaml清单文件。本质上，我只是想在我的入口清单文件中参数化path，给它不同的路径，我想让它"追加"。到我的ALB的监听规则，我在考虑&;listenerrulepriority &;有相关性。然而，我不知道"listenerrulepriority"的概念在哪里出现的原因。这是怎么回事?
你应该为每个应用创建一个入口资源，例如一个用于microservice1，一个用于microservice2。
将有它自己的路径，例如:inress for microservice1可能有
/microservice1
和microservice2的入口资源可能有
/microservice2
然后在集群中，通常有一个解释入口资源的入口控制器。在AWS EKS上，这通常是AWS负载平衡控制器，它将管理一个AWS应用程序负载平衡器，并将来自集群中入口资源的所有路径附加到该负载平衡器。
。两种:
/microservice1
/microservice2
注意:这最近在AWS EKS上发生了变化:引入AWS负载平衡控制器。介绍AWS负载平衡器控制器的博文很好地描述了变化和功能。