我是 kubernetes 的新手,只是在 k8s 上做很少的研发。正在检查不同的部署策略,例如滚动更新、重新创建、蓝绿和金丝雀。如果是正确的,金丝雀部署背后的想法是向一组用户推出新版本。在这里,我的问题让我的团队拥有开发人员和测试团队。每当测试团队尝试访问应用程序时,它应该重定向到新版本的应用程序,这可能吗?还是金丝雀仅用于通过一项服务同时运行 2 个版本的应用程序?
2 回答
金丝雀部署
如果是正确的,金丝雀部署背后的想法是向一组用户推出新版本。在这里,我的问题让我的团队拥有开发人员和测试团队。
据我所知, 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"]
是的,如果您将 Kubernetes 集群与 isito 一起使用,您可以管理金丝雀部署,将特定用户流量移动到特定版本。
基于粘性会话,您还可以管理特定用户每次获得新版本。
有很多方法可以处理这种情况,例如,您可以通过注入一些标头来实现。
对于特定用户,传递一些特定的标头并基于该路由从 isito 到新版本的流量。