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

Question

我是 kubernetes 的新手，只是在 k8s 上进行了很少的研发。正在检查不同的部署策略，例如滚动更新、重新创建、蓝绿和金丝雀。如果我是正确的，金丝雀部署背后的想法是向一组用户推出新版本。我的问题让我的团队拥有开发人员和测试团队。每当测试团队尝试访问应用程序时，它应该重定向到新版本的应用程序，这可能吗？或者金丝雀仅用于让 2 个版本的应用程序与一项服务同时运行？

Answer 1

金丝雀部署

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

据我所知，金丝雀部署这个术语没有精确的定义。但这通常意味着您部署应用程序的新版本，并且只让一小部分流量到达新版本，例如 5% 或 15% - 然后使用Canary 分析器（例如Kayenta）来分析应用程序的指标新版本和旧版本 - 然后自动决定将所有流量路由到新版本或回滚部署。

这样做的好处是高度自动化 - 人类无需在部署后监控指标。如果新版本中存在错误，则只有一小部分客户受到影响。但这也具有挑战性，因为您需要一定量的流量才能获得良好的统计基础。

基于用户属性的路由

每当测试团队尝试访问应用程序时，它应该重定向到新版本的应用程序，这可能吗？

这里您想要的是根据用户的属性（例如来自身份验证令牌）将流量路由到特定版本。

您需要一个服务网格（例如Istio），并基于JWT（例如OpenID Connect）进行身份验证，以便在 Kubernetes 中执行此操作。

从Istio 文档中，您需要为您的应用程序创建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和列表类型声明部分描述了如何为特定用户名 ( sub) 或具有 的属性/用户组指定规则claims。例如

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