V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
resouer
V2EX  ›  云计算

大家在生产环境中用 Helm 么?大致用到什么程度?

  •  
  •   resouer · 2019-06-18 01:35:37 +08:00 · 8250 次点击
    这是一个创建于 1736 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近 Helm 官方跟我们团队沟通,希望从技术和社区多个渠道上合作在国内普及与推广 Helm。

    对这个我们非常欢迎,国内 K8s 应用管理这块,跟社区差距还是有点大的。但是:

    不知道大家在生产环境中用 Helm 么?大致用到什么程度?

    先说我的看法:

    1. Helm 在国外的普及程度是非常高的,说是 CNCF 里除了 K8s,Prometheus 之外的 NO.3 应该没异议。
    2. Helm 本身在应用定义方面做得不错,但是它试图连整个应用的管理周期都管下来的做法是有问题的。我们和 Google 正在跟 Helm 聊 Helm 拆分,但还非常早期。
    3. 结合 2,Helm 对 Release 和“发布”的管理功能,堪称鸡肋。
    4. Templating 和 DSL 是定制应用参数比较差的做法,我们在用 Overlay ( Kustomize ) 做这件事情。

    Feel free to feedback!

    35 条回复    2021-04-25 14:28:39 +08:00
    dangyuluo
        1
    dangyuluo  
       2019-06-18 01:41:29 +08:00
    半年用一次,部署完拉到
    resouer
        2
    resouer  
    OP
       2019-06-18 02:13:14 +08:00
    @dangyuluo 可以,我们就喜欢这个用法,helm 其它功能太鸡肋了
    binux
        3
    binux  
       2019-06-18 02:31:28 +08:00   ❤️ 1
    我们的 k8s 集群是我部署和定义的。我禁止在生产环境中使用 helm。
    1. 我们主要用 k8s 部署我们自己的应用,既然要自己写 yaml,没有必要使用 helm。
    2. Tiller 完全就是一个后门,它绕过 k8s 自己的权限认证。
    3. chart 虽然方便,但是很难保证过一两年你安装的配置和原来的兼容。

    既然这样,还不如直接管理 yaml,要用 Helm 也是渲染出 yaml 去 apply。
    resouer
        4
    resouer  
    OP
       2019-06-18 02:44:39 +08:00
    @binux Tiller 这个东西确实变态。

    > 要用 Helm 也是渲染出 yaml 去 apply

    我们现在是将 Helm Charts Kustomize 化,这样 Base Charts 更新了,你的应用 YAML 就可以做 Rebase。感觉更符合你的使用场景?
    binux
        5
    binux  
       2019-06-18 02:59:26 +08:00
    @resouer #4 对于我们来说第三方应用非常非常少,自己的应用需要的不过是 staging/prod 的一些变量的替换罢了。用 template 可以一套变量用在多个地方(比如 SQS name 可以同时用在 k8s yaml 和 Cloudformation 上)。
    resouer
        6
    resouer  
    OP
       2019-06-18 04:49:01 +08:00
    @binux 那应用描述与应用依赖关系怎么定义? DIY 方案?
    binux
        7
    binux  
       2019-06-18 04:54:38 +08:00
    @resouer #6 是啊,terraform 对 k8s 支持不成熟,没办法啊。
    YzSama
        8
    YzSama  
       2019-06-18 06:09:25 +08:00 via iPhone
    我觉得这东西很好用啊,对于很多开发人员,他们根本不关心服务部署在哪,配置要怎么写。 用 helm 就可以随时调整配置文件,定义几套模板就好了。不必下发到各项目中,集中管理部署模版
    resouer
        9
    resouer  
    OP
       2019-06-18 06:13:53 +08:00
    @YzSama 那么应用安装好之后的发布回滚流程,倾向于让 Helm 管么?
    tontinme
        10
    tontinme  
       2019-06-18 07:30:13 +08:00 via Android
    用的 kustomize 管理 base,ansible template 生成 patch。
    silenceshell
        11
    silenceshell  
       2019-06-18 07:37:40 +08:00 via Android
    @binux tiller 可以部署在自己的 namespace 里,只是浪费一些资源
    helm3 有改善
    monsterxx03
        12
    monsterxx03  
       2019-06-18 07:43:43 +08:00
    第三方应用的 chart(jenkins,sonarqube...) 我的做法是直接 cp 到自己的 repo 里, 在里面加一个文件夹 helm_vars 用来 override values.yaml 里面的值, 更新时候直接再从上游拷过来覆盖一次,看 git diff, 没问题再 helm upgrade xx . -f helm_vars/prod.yaml( 这句写死在 Makefile 里). 这种应用更新频率很低直接让 helm 管理了.

    自己的应用也用 helm 初始化, 后续更新一般都是代码的更新, 只更新 image tag, 不走 helm, 在 jenkins pipeline 用 kubeclt set image + kubectl rollout status 更新. image 都是时间戳, 每次发布新的 image 同时把 latest tag 指向最新的 tag. helm chart 里 image 永远写 latest.

    自己的应用只有在改应用运行环境的时候才需要执行 helm upgrade (很少很少), 风险是此时 tag 变成了 latest, 如果之前线上做了 rollback 就会处问题(但只有我有这权限,所以问题不大)

    helm 的依赖管理对我真的没啥用处,有的 chart 里有 requirements 的,我都想办法禁掉, 单独部署它的依赖
    anubu
        13
    anubu  
       2019-06-18 07:48:30 +08:00
    主要在 CI/CD 环节使用,helm template + kubectl,no tiller。真的只是替换一些环境参数,不管是 template 还是 overlay,不要搞太复杂。可能是程序规模较小,依赖完全可控,人工管理。回滚方面倾向于代码层面回滚,重新发布新的 release,发布流程不变。考虑重新编译时间较长,也可以制品回滚。
    twl007
        14
    twl007  
       2019-06-18 08:10:20 +08:00 via iPhone
    @resouer 但是对于上百个重复生成的问题怎么解决呢? Kustomize 要是有上百个 overlay 也不好管理吧。我们现在对于一些不是要生成上百个,每个之间也仅仅是参数不同。

    另外 jsonnet 也可以考虑下。
    sampeng
        15
    sampeng  
       2019-06-18 08:15:11 +08:00 via iPhone
    我一直纠结的是不是线上要用 helm 的 tiller …因为有近 40 个微服务。全是 template 会有点方。但 tiller 真的就像上面说的,这万一跟后门一样…纠结啊
    jessynt
        16
    jessynt  
       2019-06-18 08:20:54 +08:00 via iPhone
    用,但是会在需要 Helm 的各个 namespace 部署 tiller
    jade88
        17
    jade88  
       2019-06-18 08:57:56 +08:00
    不用,自己封装了一个类似的
    recall704
        18
    recall704  
       2019-06-18 11:14:02 +08:00
    没用,等 3
    artandlol
        19
    artandlol  
       2019-06-18 11:21:18 +08:00 via Android
    不用内置 tiller 版本出来了吗
    Ley
        20
    Ley  
       2019-06-18 11:29:28 +08:00 via Android
    Helm 和 kubectl 似乎有不兼容之处。通过 Helm ungrade 更新的资源如果用 kubectl apply 之后就无法再次被 Helm 更新。诸如此类的问题遇到几个,给人感觉 Helm 成熟度还不够
    ps1aniuge
        21
    ps1aniuge  
       2019-06-18 13:22:19 +08:00
    Helm 在我眼中,是解决集群应用,有状态应用的。 的幺蛾子。

    我看好 operater。但 operater 太少。
    这相当于给 k8s 注入功能。或许谷歌会偷偷封杀,设置障碍。
    同时由于 k8s 更新频繁,operater 面临兼容新版本问题。

    并不能怪他俩。甚至第三个冒出来的小弟。
    毕竟有状态应用,集群应用本身就是,k8s 的癌症。

    彻底改写应用架构,逻辑,以适应 k8s 集群。这个最难,当然效果也最好。
    YzSama
        22
    YzSama  
       2019-06-18 15:45:31 +08:00
    @resouer #9 等 V3,感觉新版本有看头。目前采用的是 env 注入模板。还能用着先。但是,管理起来太麻烦了。 观望下半年和服务
    unco020511
        23
    unco020511  
       2019-06-18 16:21:58 +08:00
    我以为你说的是 mac 下的 host 切换软件...
    xbigfat
        24
    xbigfat  
       2019-06-18 17:20:31 +08:00
    @unco020511 我也是这么以为的。。。
    xfriday
        25
    xfriday  
       2019-06-18 22:45:14 +08:00
    目前只用 kubectl,生成 configmap 会用到 kustomize 的 configMapGenerator
    hyuwang
        26
    hyuwang  
       2019-06-19 02:44:15 +08:00
    开始用了一段时间 template + apply
    之后干脆直接 tiller+tls 分集群了

    还是要等 v3 搭配 helm-secrets 这种插件非常好用
    resouer
        27
    resouer  
    OP
       2019-06-19 03:49:54 +08:00
    @twl007 生成出来的 patch 多还好吧,我们通过 Git 组织起来, 不过看起来缺失一个面向 Git 的应用管理工具来操作这些 patch。另外我其实觉得生成 Patch 的过程比较难弄,感觉少一个像 Dockerfile 这种的文件。。。
    resouer
        28
    resouer  
    OP
       2019-06-19 03:52:06 +08:00
    @sampeng v3 没有 tiller 了,但我们觉得 Helm templating 实际上问题也不小
    resouer
        29
    resouer  
    OP
       2019-06-19 03:52:48 +08:00
    @Ley 对的,我们目前对 Helm 的用法,就是只把它当包管理使用,后面的流程都是 kubectl
    resouer
        30
    resouer  
    OP
       2019-06-19 03:53:29 +08:00
    @monsterxx03 感谢分享,你们的这个 workflow 感觉很典型
    resouer
        31
    resouer  
    OP
       2019-06-19 03:58:44 +08:00
    @ps1aniuge 这里理解有点偏差,Helm 重点解决的是应用定义和打包的静态问题,Operator 解的是有状态应用怎么部署运行升级的动态问题。当然,现在 Helm 有点想往后吃动态的部分,做的很差。关于 Operator 的沿革和未来,以及它和有状态应用的关系,不知道有没有读过我们之前的这篇文章: https://www.lijiaocn.com/%E9%A1%B9%E7%9B%AE/2019/01/08/kubernetes-api-and-operator-history.html
    resouer
        32
    resouer  
    OP
       2019-06-19 04:39:27 +08:00
    sampeng
        33
    sampeng  
       2019-06-19 08:15:01 +08:00 via iPhone
    @resouer 没有银弹的。完美的东西本身是不存在的。但有几十个微服务。再加 n 套环境。反正我觉得现在 helm 是最舒服的。用其他的我基本得累死…

    之前 tiler 也不是不能用吧…
    leeeee9
        34
    leeeee9  
       2021-04-24 14:16:29 +08:00
    helm 现在是 3 tiler 还有这个概念吗?还是说 helm 直接解析去调用 apiserver ?
    resouer
        35
    resouer  
    OP
       2021-04-25 14:28:39 +08:00
    @leeeee9 没有了,helm 3 把状态保存在 server 端,然后在 cli 里处理
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5112 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 03:55 · PVG 11:55 · LAX 20:55 · JFK 23:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.