chengzhycn commented on issue #12664:
URL: https://github.com/apache/apisix/issues/12664#issuecomment-3405249001
@hanqingwu @Baoyuantop
```
+-------------+
svcA.domainA.com | Service a |
+-------------- |
|
+-------------+
*.domainA.com resolve to +--------------+ |
ClusterA's Ingress | ClusterA | |
+---------- | Ingress |----+
| | | |
+-------------+
| +--------------+ |
| Service b |
|
+-------------- |
|
svcB.domainA.com +-------------+
+--------------+ |
unified.domain.com | | |
---------------------------------------------
--------------------| APISIX |-------+
| | | +--------------+
+-------------+
+--------------+ | | ClusterB |
| Service c |
+-----------| Ingress
|------------------+ |
*.domainB.com resolve to | |
+-------------+
ClusterB's Ingress +--------------+
svcC.domainB.com
*.
```
A simple traffic architechture likes above.
Users access these services using APISIX and the domain
`unified.domain.com`. These services may be scheduled to different clusters.
Furthermore, APISIX needs to ensure that services a, b, and c receive equal
traffic. A limitation in this scenario is that **services can only be exposed
via the Ingress, which only has one IP:port per cluster.**
Given that users only see a single unified domain (unified.domain.com),
creating multiple routes with host matching in APISIX does not seem possible.
(However, it's worth noting that we currently use host-matching to split
traffic at ClusterA's Ingress.)
A potential workaround for this is to merge services a and b into a single
service and adjust ClusterA's weight in APISIX. However, this does not fully
meet the business's request.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
