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

Question

我对库伯奈特来说是新手，只是在k8s上做一些小的研发工作。正在检查不同的部署策略，如滚动更新、重新创建、蓝绿色和金丝雀。如果我是正确的，金丝雀部署背后的想法是推出新的版本来设置用户。在这里，我的问题让我的团队有开发人员和测试团队。无论何时测试团队试图访问应用程序，它都应该重定向到新版本的应用程序，这是可能的吗？还是金丝雀只用于同时运行两个版本的应用程序和一个服务？

Answer 1

是的，如果您使用您的Kubernetes集群，同时使用isito，您可以管理金丝雀部署，将一个特定的用户流量移动到一个特定的版本。

根据粘性会话，您还可以管理特定用户每次获得新版本。

有很多方法来处理这个场景，例如，您可以通过注入一些头来完成它。

对于特定的用户，传递一些特定的标头，并在此基础上将通信量从isito发送到新版本。

Answer 2

加那利部署

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

金丝雀部署一词并没有我所知道的确切定义。但这通常意味着您部署了新版本的应用程序，只让一小部分流量到达新版本，例如5%或15%，然后使用金丝雀分析器(例如凯伦塔)分析新版本和旧版本的指标，然后自动决定将所有流量路由到新版本或回滚部署。

这样做的好处是高度的自动化--在部署之后，人类不需要监视这些指标。如果新版本中有错误，那么只有一小部分客户会受到影响。但这也是一个挑战，因为你需要一定数量的流量作为一个良好的统计基础。

基于用户属性的路由

无论何时测试团队试图访问应用程序，它都应该重定向到新版本的应用程序，这是可能的吗？

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

您需要一个类似于伊斯蒂奥的服务网格，并将您的身份验证建立在JWT (例如OpenID连接 )的基础上，以便在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"]