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

Question

我希望这是有道理的。

我们目前通过 CloudFormation 脚本在 ECS 中部署我们的微服务，使用我们为每个微服务填写的参数化 CloudFromation 模板。我们使用配置有多个 /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 调用时，它会转到微服务 1 等

我们通过此 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对应关系，想参数化一个微服务-ingress.yamlmanifest文件。本质上，我只是想在我的入口清单文件中参数化 path 以给它不同的路径，我希望它“附加”到我的 ALB 的侦听器规则，我认为“ListenerRulePriority”有关联。但是，我不知道“ListenerRulePriority”这个概念是从哪里来的，它是怎么来的？

Answer 1

您应该为每个应用程序创建一个 Ingress-资源，例如一个用于微服务 1，一个用于微服务 2。

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

/microservice1

微服务 2 的 Ingress 资源可能有

/microservice2

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

例如两者：

/microservice1
/microservice2

注意：这最近在 AWS EKS 上发生了变化：Introducing AWS Load Balancer Controller. The blog post Introducing the AWS Load Balancer Controller 对变化和功能很好。

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

Translating an AWS Cloudformation resource into an EKS ingress configuration?

amazon-web-services

kubernetes

kubernetes-ingress

amazon-eks

aws-application-load-balancer