httproutes with same name in different clusters in the same service network fails to route

[costap]

When creating multiple http route configs in different clusters with the same name that are part of the same VPC Lattice service network, Lattice seems to fail to route requests. Further more if you delete one of the http route configs from one the clusters but leave the other, it removes the service completely from the service network although the other route still exists.

Not sure if running the same service in different clusters is an actual use case that VPC Lattice supports but even if not feel it should handle it somehow more elegantly rather then fail to route traffic.

Steps to reproduce.

1. in the same account, same region, create two EKS clusters in different VPCs with VPC Lattice Gateway Controller configured.
2. In cluster 1 deploy:
   • examples/inventory-ver1.yaml
   • examples/inventory-ver2.yaml
   • examples/my-hotel-gateway-multi-listeners.yaml
   • examples/inventory-route-bluegreen-https.yaml
3. Verify inventory service has been created in VPC Lattice and thats possible to make requests to it.
4. In cluster 2 deploy:
   • examples/inventory-ver1.yaml
   • examples/inventory-ver2.yaml
   • examples/my-hotel-gateway-multi-listeners.yaml
   • examples/inventory-route-bluegreen-https.yaml
5. Verify is no longer possible to make requests to inventory service through the Lattice service DNS name.

EXPECTED:
5a. You could call inventory services and would load-balance requests across clusters

---

6. In Cluster 2 remove examples/inventory-route-bluegreen-https.yaml
7. Verify that service in VPC Lattice has been deleted

EXPECTED:
7a. Inventory VPC Lattice service still configured and can route requests to targets in cluster 1.

Inventory target group:

Environment:

Controller Image: public.ecr.aws/m7r9p7b3/aws-gateway-controller:v0.0.17
EKS Version: v1.27.6-eks-f8587cb

[mikhail-aws]

Hi, thank you for filing issue. There is ongoing work on resource ownership and naming. It will be addressed in following releases. I will update this thread.

[mikhail-aws]

@solmonk can you take a look, please?

[solmonk]

Having services with the exact same name across different clusters is currently not supported, but this is an issue we would like to address on #466. From this change, we specify a concrete "ownership" of a resource, so multiple clusters overwriting each other's rules will not be allowed.

[graehren]

@costap We released EKS controller version v0.0.18 yesterday which contains a revised TG naming strategy to avoid conflicts. Target group names will no longer conflict across clusters for identical specs. Target group names now include a randomized suffix and all identification/deduplication is done through first class fields on the target group and tags.

Marking this issue as resolved. Thank you for you support.

[costap]

Hi, not sure I understand if this supported now? I'm still seeing this issue tested with v1.0.2 and that PR sems to be included. @solmonk

I now see both TGs but the service only routes to one of them? is that the expected behaviour?

On the second cluster k8s route resource I see this error:

  status:
    parents:
    - conditions:
      - lastTransitionTime: "2024-01-05T16:57:59Z"
        message: 'error during service synthesis failed ServiceManager.Upsert server-rpc-server-app
          due to service server-app/server-rpc had a conflict: Found existing resource
          not owned by controller: arn:aws:vpc-lattice:eu-west-1:xxxxxxx:service/svc-xxxxx8ca'