官方 helm charts V.S. bitnami helm charts V.S. 官方 operator，大家一般倾向于用哪个？
eephee 2024-06-25 20:57:01 +08:00 3285 次点击这是一个创建于 471 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如在部署 elk stack, prometheus stack 的时候，挑得我都眼花了，不知道该用哪个好了
之前挑来挑去，最后还是自己写了 k8s manifest ，没整太多花里胡哨的，但是费时间...
 | 1 jackge0323 2024-06-25 20:59:38 +08:00  1 有官方 helm 用 helm ，没有的话，用官方 operator ，最后用 bitnami |
 | 2 yinheli 2024-06-25 21:31:55 +08:00 得具体分析，大部分的 case 是： - 官方 helm 的可配置性还可以，版本维护会比较及时，优先选择 - operator 不管是官方还是三方，很多时候的可配置性都比较差，特别是你有各种节点亲和性以及自己的一些配置需求的时候 - bitnami 的配置大部分继承了它的 commons ， 如果你用过其他的，学习迁移成本比较低 我的倾向则完全要看情况，可能都会在实验环境测试一番，体验下哪种运维方便稳定性更好。 |
 | 3 Int100 2024-06-26 01:25:43 +08:00 via iPhone 要看具体情况，Prometheus Stack 我也是 manifest 一套拉下来自己按需求修改的。 其他的，如果官方 helm 写的好就直接用。 bitnami 放最后才考虑。 |
 | 4 chf007 2024-06-26 09:48:52 +08:00 如果开发测试用，哪个方便拉哪个，最好官方的 如果生产用，比较独立的话，用官方的。定制多的，研究一下拉下来自已改，但是版本更新什么的要自已一点一点跟 |
 | 5 eephee OP 感谢，那我就不考虑 bitnami 了 |
 | 6 zx900930 2024-07-14 07:55:06 +08:00 其实，大概率你都要自己改的（比如去除你不需要的组件 - 新增一些第三方的 DP 和 exporter 或者 crd ）。 所以选一个和自己的使用场景最接近的 operator 然后再修改就好了。 |
Select Language