问题描述
我对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到新版本的流量。