我正在考虑在 Istio 中使用金丝雀部署,但它似乎会根据权重将请求随机分配到新旧版本。这意味着业务中的用户可能会在一分钟内看到一种行为,下一分钟会看到不同的行为,并且团队中的人可能会遇到彼此不同的行为。出于这个原因,如果我希望用户或团队的行为保持一致,我需要建立自己的推出机制,我可以控制谁继续使用新的服务版本。
我是正确的还是我误解了 Istio 金丝雀推出的工作原理?
我正在考虑在 Istio 中使用金丝雀部署,但它似乎会根据权重将请求随机分配到新旧版本。这意味着业务中的用户可能会在一分钟内看到一种行为,下一分钟会看到不同的行为,并且团队中的人可能会遇到彼此不同的行为。出于这个原因,如果我希望用户或团队的行为保持一致,我需要建立自己的推出机制,我可以控制谁继续使用新的服务版本。
我是正确的还是我误解了 Istio 金丝雀推出的工作原理?
如果你按权重做一个基本的流量分配,你是对的。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld
spec:
hosts:
- helloworld
http:
- route:
- destination:
host: helloworld
subset: v1
weight: 90
- destination:
host: helloworld
subset: v2
weight: 10
这里 10% 的流量是v2
随机路由的。任何请求都可能调用不同的版本。
但是你可以做更复杂的路由。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld
spec:
hosts:
- helloworld
http:
- match:
- headers:
group:
exact: testing
route:
- destination:
host: helloworld
subset: v2
- route:
- destination:
host: helloworld
subset: v1
现在有两条路线:
此示例中的标头可以根据用户在前端设置,因此该用户的后端请求将调用 v2.
或者,您可以为特定组设置 cookie,并使用以下方法将它们路由到不同的前端:
- match:
- headers:
cookie:
[...]
有多个匹配条件,headers
包括queryParams
和authority
。