金丝雀推出的实际问题

Question

我正在考虑在Istio中使用canary部署，但它似乎会根据权重将请求随机分配到新版本和旧版本。这意味着业务中的用户可以在前一分钟看到一种行为，而在下一分钟看到不同的行为&团队中的人可能会经历彼此不同的行为。出于这个原因，如果我想让用户或团队保持一致的行为，我需要建立自己的推出机制，在那里我可以控制谁进入新的服务版本。

我是对的还是误解了Istio canary的推出方式？

Answer 1

如果您按权重进行基本流量分配，那么您是正确的。

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%的业务被随机地路由到CCD_ 1。任何请求都可能调用不同的版本。

但你可以做更复杂的路由。

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
• 所有其他用户都将被发送到v1

本例中的头可以根据用户在前端设置，因此该用户的后端请求将调用v2。

或者你可以为一个特定的组设置一个cookie，并使用以下方法将它们路由到不同的前端：

- match:
- headers:
cookie: 
[...]

有多个匹配标准，包括headers、queryParams和authority。