admin管理员组文章数量:1122832
we are trying to achieve canary strategy for our micro-services running in aks cluster. we followed a very good article on this and was able to setup the canary for our miro services.
here we have a header called x-canary enabled to decide and route the traffic over the canary and prod version ( if x-canary: true, then always to canary release version irrespective of the weight set and if the x-canary header is false, the traffic should be to both prod and canary as per weightage set).
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: myapp
namespace: myappnamespace
spec:
gateways:
- mesh
- "istio-system/ingress-gateway"
hosts:
- "myapp.myappnamespace.svc.cluster.local"
- "myapp.services.mydomain"
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: myapp.myappnamespace.svc.cluster.local
port:
number: 8080
subset: canary
- match:
- uri:
prefix: "/"
retries:
attempts: 0
route:
- destination:
host: "myapp.myappnamespace.svc.cluster.local"
port:
number: 8080
subset: production
weight: 50
- destination:
host: "myapp.myappnamespace.svc.cluster.local"
port:
number: 8080
subset: canary
weight: 50
But Here we are not able to achieve different production ready scenarios like, suppose if we have apps A and B with primary (A, B) and canary with (A1 and B1)
here we would need dynamic routing scenarios between this apps.
1) Primary A to Primary B
2) Primary A to Canary B1
3) Canary A1 to primary B
4) Canary A1 to Canary B1
here I just took 2 apps as example and there can be many apps running with different prod or canary versions and these routing scenarios should be dynamic
As per documents, I guess I need to use of dynamic Header Propagation and inject headers to the source apps and this need to be veriied by the Destination apps on the receival of the request from Source.
we are trying to achieve canary strategy for our micro-services running in aks cluster. we followed a very good article https://medium.com/microsoftazure/canary-release-strategy-using-kubernetes-istio-helm-fb49c0406f07 on this and was able to setup the canary for our miro services.
here we have a header called x-canary enabled to decide and route the traffic over the canary and prod version ( if x-canary: true, then always to canary release version irrespective of the weight set and if the x-canary header is false, the traffic should be to both prod and canary as per weightage set).
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: myapp
namespace: myappnamespace
spec:
gateways:
- mesh
- "istio-system/ingress-gateway"
hosts:
- "myapp.myappnamespace.svc.cluster.local"
- "myapp.services.mydomain.com"
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: myapp.myappnamespace.svc.cluster.local
port:
number: 8080
subset: canary
- match:
- uri:
prefix: "/"
retries:
attempts: 0
route:
- destination:
host: "myapp.myappnamespace.svc.cluster.local"
port:
number: 8080
subset: production
weight: 50
- destination:
host: "myapp.myappnamespace.svc.cluster.local"
port:
number: 8080
subset: canary
weight: 50
But Here we are not able to achieve different production ready scenarios like, suppose if we have apps A and B with primary (A, B) and canary with (A1 and B1)
here we would need dynamic routing scenarios between this apps.
1) Primary A to Primary B
2) Primary A to Canary B1
3) Canary A1 to primary B
4) Canary A1 to Canary B1
here I just took 2 apps as example and there can be many apps running with different prod or canary versions and these routing scenarios should be dynamic
As per documents, I guess I need to use of dynamic Header Propagation and inject headers to the source apps and this need to be veriied by the Destination apps on the receival of the request from Source.
Share Improve this question asked Dec 22, 2024 at 13:45 VowneeeVowneee 1,44923 silver badges64 bronze badges1 Answer
Reset to default 1As reported at the following link:
https://www.opsmx.com/blog/how-to-perform-canary-with-argo-rollouts-and-istio-service-mesh/
Istio can split the traffic, but an agent is needed to update the traffic percentage based on some analysis. So you need istio + argo rollouts.
Istio can be used in two ways:
-By treating two versions of an application, canary (new version) and stable (old version) as two separate services in Kubernetes.
-By treating two versions as the subset of the single application. In this case service in Kubernetes will have two different Deployments attached.
I suppose we are in the second case.
You can find a further guide at the following link:
https://newrelic.com/blog/how-to-relic/canary-releases-new-relic-argo-rollouts
I expect you have a destination rule similar to this one:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: rollout-ds
namespace: myappnamespace
spec:
host: "myapp.myappnamespace.svc.cluster.local"
subsets:
- name: production
labels:
version: production
- name: canary
labels:
version: canary
本文标签: kubernetesistio canary strategy with dynamic routing rules with different appsStack Overflow
版权声明:本文标题:kubernetes - istio canary strategy with dynamic routing rules with different apps - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1736393938a1944311.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论