Translating an AWS Cloudformation resource into an EKS ingress configuration?

Question

I hope this makes sense.

We currently deploy our microservices in ECS via CloudFormation script, using a parameterized CloudFrormation template that we fill out per microservice. We use a single ALB configured with multiple /path rules, where each rule is for a microservice. So essentially our listener rules looks like

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

So when our application sends a RESTful API call to api.company.com/microservice1/some_path/... it goes to microservice1, etc.

We create each listener rules via this CloudFormation resource

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

With this, we can just add paths to our ALB, as we build microservices. Each microservice has its corresponding "ListenerRulePriority" number that we calculate on the fly. Make sense?

I understand the 1:1 correspondence between the ALB above and a Kubernetes Ingress resource, and I want to parameterize a microservice-ingress.yaml manifest file. Essentially, I just want to parameterize the path in my ingress manifest file to give it different paths, and I want it to "append" to the listener rules of my ALB, and I'm thinking the "ListenerRulePriority" has relevance. However, I don't know where the concept of "ListenerRulePriority" comes in. How does it?

Answer 1

You should create an Ingress-resource for each application, e.g. one for microservice1 and one for microservice2.

The will have its own paths, e.g. Ingress for microservice1 may have

/microservice1

and the Ingress resource for microservice2 may have

/microservice2

Then in the cluster, you typically have an Ingress-controller that interpret the Ingress-resources. On AWS EKS this is typically AWS Load Balancer Controller and it will manage one AWS Application Load Balancer and will append all paths from Ingress-resources in your cluster to this load balancer.

E.g. both:

/microservice1
/microservice2

Note: this has recently changed on AWS EKS: Introducing AWS Load Balancer Controller. The blog post Introducing the AWS Load Balancer Controller is good about the changes and functionality.