在Canary部署策略中，将特定用户重定向到具有新版本的Pod

如何解决在Canary部署策略中，将特定用户重定向到具有新版本的Pod

我对kubernetes只是陌生的，只是很少在k8s上进行研发。 正在检查不同的部署策略，例如滚动更新，重新创建，蓝绿色和金丝雀。如果是正确的话，金丝雀部署的想法就是向用户群推出新版本。在这里，我的问题使我的团队拥有开发人员和测试团队。每当测试团队尝试访问该应用程序时，应将其重定向到新版本的应用程序，这可能吗？或canary仅用于通过一项服务同时运行2个版本的应用程序？

解决方法

金丝雀部署

如果是正确的话，金丝雀部署背后的想法是向用户群推出新版本。在这里，我的问题使我的团队拥有开发人员和测试团队。

我所知道的术语 Canary Deployment 没有确切的定义。但这通常意味着您部署了新版本的应用，并且只让一小部分流量访问了新版本，例如5％或15％-然后使用 Canary Analyzer （例如Kayenta）来分析新版本和旧版本的指标-然后执行自动决策将所有流量路由到新版本或回滚部署。

这样做的好处是高度的自动化-部署后，人们不必监视指标。而且，如果新版本中存在错误，则只会影响一小部分客户。但这也是一个挑战，因为您需要一定数量的流量才能获得良好的统计基础。

基于用户属性的路由

每当测试团队尝试访问该应用程序时，都应该将其重定向到新版本的应用程序吗？

您此处想要的是根据用户的属性（例如，通过身份验证令牌。

您需要一个服务网格，例如Istio，并基于JWT进行身份验证，例如OpenID Connect在Kubernetes中做到这一点。

您需要从Istio documentation为您的应用创建一个RequestAuthentication和一个AuthorizationPolicy。

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "issuer-foo"
  - issuer: "issuer-bar"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
 rules:
 - from:
   - source:
       requestPrincipals: ["issuer-foo/*"]
   to:
     hosts: ["example.com"]
 - from:
   - source:
       requestPrincipals: ["issuer-bar/*"]
   to:
     hosts: ["another-host.com"]

文档的JWT and list-typed claims部分介绍了如何使用sub为特定用户名（claims）或用户的属性/用户组指定规则。例如

    when:
    - key: request.auth.claims[groups]
      values: ["test-group"]

,

是的，如果您将Kubernetes群集与isito一起使用，则可以管理canary部署，将一个特定的用户流量转移到特定的版本。

基于粘性会话，您还可以管理每次使用新版本时获得的特定用户。

有很多方法可以处理这种情况，例如，可以通过注入一些标头来实现。

对于特定用户，传递一些特定的标头，并根据该路由从isito到新版本的流量。