金丝雀推出的实际问题

Question

我正在考虑在 Istio 中使用金丝雀部署，但它似乎会根据权重将请求随机分发到新旧版本。这意味着业务中的用户前一分钟可以看到一种行为，下一分钟可以看到不同的行为，并且团队中的人可以体验到彼此不同的行为。出于这个原因，如果我想要用户或团队的一致行为，我似乎需要构建我自己的推出机制，我可以控制谁移动到新的服务版本。

我是对的还是我误解了 Istio 金丝雀部署的工作原理？

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% 的流量随机路由到 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

现在有两条路线：

具有 header group=testing 的用户将被发送到 v2
所有其他用户将被发送到 v1

本例中的header可以在前端根据用户进行设置，所以该用户的后端请求会调用v2.

或者您可以为特定组设置 cookie 并使用类似以下内容将它们路由到不同的前端：

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

有multiple match个条件，包括headers、queryParams和authority。

金丝雀推出的实际问题

Practical problems with canary rollout

istio

canary-deployment