tokers opened a new issue #441: URL: https://github.com/apache/apisix-ingress-controller/issues/441
### Issue description Currently, when we specify a Kubernetes service in `ApisixRoute` as the backend, we push all endpoints/pod to the target upstream in APISIX. Sometimes a Kubernetes Service will contain multiple versions, for instance, some endpoints are `v1` while others are `v2`. Users might need to do some traffic management among these different releases. But this is not feasible in apisix-ingress-controller. So a subset can be introduced when we select a Kubernetes Service as the backend, just like what istio [provides](https://istio.io/latest/docs/reference/config/networking/destination-rule/), for instance: ```yaml apiVersion: apisix.apache.org/v2alpha1 kind: ApisixRoute metadata: name: foo-route spec: http: - name: foo-canary-route priority: 1 match: paths: ["/*"] hosts: ["foo.org"] exprs: - subject: scope: Cookie name: sessionid op: Equal value: "33333" backend: serviceName: foo servicePort: 80 subset: name: v2-subset labels: version: v2 app: foo - name: foo-stable-route priority: 0 match: paths: ["/*"] hosts: ["foo.org"] backend: serviceName: foo servicePort: 80 subset: name: v1-subset labels: version: v1 app: foo ``` In the above example, requests which `sesssionid` in cookie is `33333` will hit the first route then forward to the subset of foo service where pods version is `v2`. For requests which don't meet the route conditions, will hit the second route then forward to the subset of foo service where pods version is `v1`. -- 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. For queries about this service, please contact Infrastructure at: [email protected]
