helm charts + istio灰度发布方案探讨

haormj

k8s 给我的个人感觉就是一个运行时环境，定义一套标准，对用户的统一的，可以抹平不同云厂商，甚至的私有云的差异，k8s 中支持的资源类型很多，甚至支持自定义，作为底层基础设施需要通用

但是作为使用方，应该从应用的维度来关联零散的资源，工作负载，服务，configmap，serviceaccount 等，目前通用的方式是 helm，提供了一种应用打包方式，从而个人感觉只要是企业在实际使用 k8s，无论是否认可应用这个维度，他都是实际存在的，你有可能不是通过 helm 打包，而是维护一个 yaml，其实都是在做应用管理

然后对于灰度而言，谈谈我个人想法

灰度的最小粒度应该是应用集群，应用部署到 k8s 中就是一个应用集群，而应用的新版本中镜像， configmap 都有发生变化，而此时的灰度应该是同样在部署一个应用集群，然后流量在两个集群之间路由，这两个集群都是完整的，有 service，workload，configmap 等

如果灰度的粒度放在同一个应用集群内，修改特定的资源会会无法满足需求，比如只支持修改工作负载中的镜像版本，但实际情况是 configmap也发生了，怎么办？

所以灰度应该将一个应用集群作为最小单位，不可分割，流量可以在新老应用集群之间做灰度

个人看法，大家可以一起讨论

zackzhang

haormj 你说的场景是想同时使用helm chart的应用与KubeSphere上的自制应用，那现在更新有两种方式：

使用KubeSphere自制应用上的灰度发布
直接使用helm upgrade --install来升级应用

使用Helm upgrade能完全满足你的要求，即 service deploy configmap等，都可以纳管进来。

KubeSphere的灰度更新方式，只是能更新镜像，不会调整配置。如果我们在灰度这个地方，加个编辑yaml的功能，应该就能满足你的需求。

另外：如果你们使用了KubeSphere的灰度功能，每次更新的时候，你们如何保证helm charts更新呢？

haormj

zackzhang

从使用角度是是这样

helm charts ks应用界面就支持升级
关于helm charts应用的灰度功能，期望在灰度界面支持选择应用和对应的版本，创建灰度后就会新创建一个应用集群，灰度在新老集群之间进行

zackzhang

haormj “创建灰度后就会新创建一个应用集群”，这个是创建灰度的时候，自动创建出一个helm chart，是这个意思吗？

haormj

@zackzhang 这样的话每个集群都有service，VirtualService需要同事拦截两个service并做weight

haormj

zackzhang 嗯嗯，我是这个意思

比如我要ironman-istio-client我需要发布新版本

老集群为ironman-hqu4gn 对应的helm charts版本号为 0.63.0+001
创建灰度的时候直接部署 ironman-istio-client 的 0.64.0+001版本，假定集群名为 ironman-xxx
ironman-hqu4gn 和 ironman-xxx 为两个独立的集群，不过都是ironman-istio-client应用，然后灰度策略就是在这两个集群之间做
现在的灰度VirtualService中的host只有当前服务，如果按照3的逻辑的话，就需要将两个集群中的服务都放到host中

zackzhang

haormj 有可行性，改动有点大。

haormj

zackzhang 不过感觉这样做灰度，对于helm charts用户，就相当于可以灰度升级，然后在增加个自动灰度策略就感觉很nice

zackzhang

haormj 你对这个需求现在应该很清楚了，有没有想过完成下，然后贡献给社区？