1

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

4

2 回答 2

3

金丝雀部署

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

据我所知, Canary Deployment一词没有一个精确的定义。但这通常意味着您部署了应用程序的新版本,并且只让一小部分流量到达新版本,例如 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"]
于 2020-08-22T15:00:37.210 回答
2

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

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

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

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

于 2020-08-21T14:14:03.120 回答