这是一个创建于 1494 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前市面上的方案大概有
- helm tiller，类似 rancher，kubermatic 的方案
- helm install，手动管理
- helm template + kubectl apply，手动管理
- kustomize 补丁方式手动管理
其他方案待补充。。。
我想问的是大家比较喜欢哪种方案？我一直觉得 helm template + kubectl apply 还行，对 GitOps 比较透明，要部署什么都很清楚，而且如果第三方 chart 有问题还可以本地加 patch，不知道大家怎么看？
另外如果大家有兴趣，我写了一个 helm template + kubectl 的 wrap app，大概功能就是为了一次性定义集群所需的所有 chart，一次性部署（项目地址： https://github.com/arhat-dev/helm-stack ), 由于是自用项目, 目前文档基本没有，欢迎大家提问提意见
第 1 条附言 · 2020-10-08 16:43:01 +08:00
还有一个 cnab, 不过到现在为止我也没搞明白到底怎么自定义部署, 还是说不应该看做是和 helm 类似的工具? 求教!
 |
1
whileFalse 2020-10-08 18:11:01 +08:00 via iPhone
借楼问 helm 和镜像构建怎么集成在一起
|
 |
2
jeffreystoke OP @whileFalse 不太理解你的问题，也不清楚你对这两个概念的认识，但是一般来说 helm 就是生成 manifest 来，这些 manifest 通常会把构建好的镜像最终以 pod 的形式部署到 kubernetes 里面
|
 |
3
wd 2020-10-08 20:16:39 +08:00 via iPhone
@jeffreystoke #2 他说的估计是镜像 build，发布一条龙吧，从代码到最后 pod
|
 |
4
anubu 2020-10-08 20:43:02 +08:00
在用第 3 种，使用第 3 种方式大部分应该是因为各种原因需要得到原始部署材料或进一步调整等。觉得这种方式进一步包装有点违背原始需求。
@whileFalse 应该是在问镜像构建完成后，helm 怎样更新部署吧？镜像构建完拿到新的 tag 在 helm 中指定 value 进行 upgrade 就可以了吧。 个人觉得应用的首次部署和后续的更新部署是两个场景，如果一个工具能够对两个场景提供较一致的操作自然是最好的，但为了一致性而牺牲了很多便利或提高了复杂度，这样的 trade-off 可能还是看具体场景，个人在日常工作中不太看好。 |
|
5
jeffreystoke OP @anubu 首次部署和后续更新确实是个痛点，我也在想又没有好的方案适配，目前还是依赖 heml template + kubectl apply --record 方便回滚，但还是会遇到 chart 更新，label 无法自动 override 而需要手动操作的情况，可能能通过 kubectl 插件实现自动化
另外虽然不是本帖重点，但是我的进一步包装是为了结构化记录集群里的所有部署，确定版本，namespace，fullname，values，extra manifest，然后通过 gitlab 之类规定只能由 pr 创建部署更改，强制 review 所有 manifest change，相当于 helm 数据库存在了一个 git repo 里，这样 chart 升级的时候就能很方便地修改 values，并且清楚地看到 manifest 变更内容，集群迁移的时候也只需要克隆一份 repo 做修改。 |
|
6
whileFalse 2020-10-08 22:49:02 +08:00
@jeffreystoke 对就是构建好的镜像是怎么来的。
@anubu 我们以前的方式： 构建镜像需要指定不同环境的 profile，所以用的 Maven 插件（命令行传了一堆参数）去生成的镜像。生成镜像后先用 kubectl get -oyaml 拉下来 deployment 的现有配置，修改镜像之后再 apply 。这一套全都是 shell 。 在这种情况下，如果仅仅把 “kubectl get”和“kubectl apply”替换为 helm，好像意义不太大的样子？ |
|
7
jeffreystoke OP  1
@whileFalse 如果只需要替换镜像可以用 kubectl set 直接修改镜像。
构建镜像要么做好规范，统一基础镜像和构建流程，要求开发合规，还可以配合 buildpacks，bazel 之类的，要么就是没有规范一堆配置和脚本。 |
|
8
jeffreystoke OP @whileFalse 拿我自己的项目举个例子，所有项目都基于一样的基础镜像 https://github.com/arhat-dev/dockerfile
然后用的时候每个项目只需要根据需要预置或提供 build-args，https://github.com/arhat-dev/template-application-python/blob/master/cicd/docker/linux.dockerfile 统一 maven 构建也是一样的 |
|
9
jeffreystoke OP @jeffreystoke 上面的 python 的例子不是很好，可以看 go 的
|
 |
10
allenyang89 2020-10-09 10:34:32 +08:00
试试 kubeapps?对我这个新手很友好，web 界面托管了 helm 部署管理。如果有不好的点还请指导一下以防继续踩坑，谢谢啦
|
|
11
jeffreystoke OP @allenyang89 看着挺好，功能很全，manifest diff 也有，感觉很适合个人使用。
反正没什么事，我就展开说说吧 我理解的网页管理模式都是比较适合第三方无状态应用的部署，可能是因为我比较懒，觉得自己维护一套私有 chart 就很累了，还要搞发布就太麻烦了 XD 另外如果想实践 gitops，网页管理就显得不够透明或者需要定制化 api，就导致了 vendor lockin （比如像 rancher 专门出了个 fleet 号称可以对接百万级 gitops ），但问题是明明可以直接通过 gitlab 跑 kubectl + oidc plugin 直接 apply 的，现在还要走通一套 oauth api 适配接口就很麻烦，可能还是因为我比较懒吧。 有没有坑看自己的判断，如 @anubu 所说，首次部署和后续更新存在差异，理想情况是有工具能自动 resolve 版本更新和当前集群状态的差异，不能 resolve 的时候提供 diff view 让用户决策，我觉得只有能做到这个才是一个没有坑的工具，但目前看来 kubeapps 提供的 diff 仅限于 values 变更而不是实际 manifest 状态变更？ 感谢你提供这么好的思考素材，让我能找到解决我目前部署痛点的方向，也就是搞一套 diff 流程自动提交 pr 对比当前集群 manifest 和新 manifest，review 过后提交 apply 。 |
|
12
jeffreystoke OP @allenyang89 第一段应该是 values diff 不是 manifest diff
|
 |
13
konakona 2020-12-15 12:46:06 +08:00
因为 helm v3 没有了 helm tiller，所以 gitlab 里没办法启用。
在首次部署的时候，我选择的是 helm template 。 后续的自动化部署也是从 gitlab cicd 里，调用 helm 更新去程序。然后可以看到 helm list 里，pod 自己在拉、更。 |
Select Language