Question

我希望这是有道理的。

我们目前通过 CloudFormation 脚本在 ECS 中部署我们的微服务，使用我们为每个微服务填写的参数化 CloudFrormation 模板。我们使用配置了多个 /path 规则的单个 ALB，其中每个规则都针对一个微服务。所以基本上我们的监听器规则看起来像

api.company.com -> alb-microservices/default -> default-target-group
                                    /microservice1/* -> microservice1-target-group
                                    /microservice2/* -> microservice2-target-group

因此，当我们的应用程序向 api.company.com/microservice1/some_path/... 发送 RESTful API 调用时，它会转到 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 Ingress 资源之间的 1:1 对应关系，我想参数化一个 microservice-ingress.yaml 清单文件。本质上，我只想参数化入口清单文件中的 path 以赋予它不同的路径，并且我希望它“附加”到我的 ALB 的侦听器规则中，我认为“ListenerRulePriority”具有关联。但是，我不知道“ListenerRulePriority”的概念从何而来，它是怎么来的？

Answer 1

您应该为每个应用程序创建一个 Ingress 资源，例如一个用于 microservice1，一个用于 microservice2。

将有自己的路径，例如微服务 1 的入口可能有

/microservice1

和 microservice2 的 Ingress 资源可能有

/microservice2

然后在集群中，您通常有一个 Ingress-controller 来解释 Ingress-resources。在 AWS EKS 上，这通常是 AWS Load Balancer Controller，它将管理一个 AWS Application Load Balancer，并将从集群中的 Ingress-resources 的所有路径附加到此负载均衡器。

例如两者：

/microservice1
/microservice2

注意：最近在 AWS EKS 上发生了变化：Introducing AWS Load Balancer Controller。博文 Introducing the AWS Load Balancer Controller 很好地介绍了更改和功能。

将 AWS Cloudformation 资源转换为 EKS 入口配置？

1 个答案: