上 Kubernetes 后，开发能自己发布吗？

开发测试环境开发自己发布，线上发布还是要审核的

得有 paas 平台啊，不会想开发直接操作 k8s 吧

公司内网的 k8s ，开发在 Jenkins 一类的 CICD 平台写点构建部署流水线，就可以自己更新，甚至交给产品自己更新了测试。外面的测试服务器，处于权限、安全、职责分离等原因，就交给专业的运维走正式流程发布更新了。
当然，项目足够小，老板或甲方同意，我们研发也可以自己发布更新。
上 k8s 后，其实更新挺简单的。

dev 环境开发自己可以发布，如果 K8S 的密钥能给，Jenkins 能把 CI 、CD 都自动化，发版就点一点，存在的问题就是没有办法设置审批节点，大家都有 dev 、prod 环境的发布权限，会乱套。

建议部署一个 Rancher 管理 K8S ，我们的 dev 、prod 是物理隔离的两套集群，根据环境给各个账号授权，隔离 dev.namespace 和 prod.namespace 。他们要发版就先在 Jenkins 点一点构建好镜像推送 dockerhub （ CI ），然后在 Rancher 里面更新版本号进行发布，领导不让完全自动化，需要人工介入 CD 的流程

@Chinchilla500 没有审批节点这块，真乱套的时候一般怎么补救？发版前群里喊一声确认，哈哈，还是谁手快谁发

我们的 ci 是用 gitlab runner 然后用 argo 做 cd ，还有一个 workflow 发布上线平台。dev 环境开发自己可以 workflow 随便自己发。只不过 pod 容量发布时候 workflow 流程会有个自动 job 限制 dev 环境发布的 pod 配置

正式环境就是开发需要提发布单然后发布流程通过钉钉通知 owner 进行审批就能上线了，sre 不参与审批默认直接通过。只有当 pod 配置需要超过 2c4g5pod 这个限制时候流程中才会通知到 sre 进行审批确认最后才能上线

开发当然能发布啊
但是不会把这个权限给所有的开发

让 AI 发布

我的 dev 、test 环境，开发/测试人员自己配置、发布流水线，生产环境运维来操作，说白了生产环境需要有人背责任

@familiar 这套 workflow 平台是自己搭的？光审批分级这块就挺细的，大概花了多久做出来？

helm+argocd+gitea+tekton+zot+s3 刚弄了这个大全套，都在集群里，这几个东西的持久化卷就用 S3

Infra 应该得做到让猪🐷 也能自己发布吧，虽然不是用 k8s 部署微服务，我们做的数据项目，Infra 设计出发点就是必须让不会写代码的小白实习生也能自己照着发布所有数据任务，参照 6 楼。

https://zhiweio.github.io/from-data-to-intelligence/30-%E5%B7%A5%E7%A8%8B%E5%B8%88%E6%97%A5%E5%B8%B8%E5%B7%A5%E4%BD%9C%E6%B5%81%E4%B8%8E%E5%8F%98%E6%9B%B4%E5%9C%BA%E6%99%AF/#_1

@defunct9 为啥有了 argocd 还用 tekton ，tekton 只做 CI 吗？

我最近落地的时候也调研了一套，最后是 helm+jenkins+coding(已经用很久了，后面切换)+aliyun acr + aliyun oss

因为 k8s 集群就是阿里云的 ack ，镜像服务之前其他部门也在用，就一起用了。

还得弄其他的基础设施，可观测性啥的，事情真不少。。

完全的 gitops ，发布更新的开发测试线上环境的时候只需要更新对应的 git 仓库的 yaml ，后面就是流水线全自动了。线上环境对应的 git 仓库 master 权限只有核心有

发布权限都是下发给开发和测试。 生产环境发布用流程限制。

我们是比较简单来说就是 gitops 模式。

为什么不能发布？能不能发，很多都时候都是组织问题，部门问题。

只要给了 K8S 密钥，想怎么发就怎么发，至于给不给，开发会不会，那就是上边的问题。

infra 可以统一制定 helm / jsonnet / ci ，做一套容器标准化发布

@fivesmallq 是，tekton 相当于你的 jenkins ，用 pipelienrun 触发构建。

@fivesmallq 怎么查问题的，几个系统人肉看，还是交给 AI 了？

@EthanWalkerTech 都交给 AI 了基本上，有一个仓库专门存放基础设施的各种配置和说明书，有问题了把 log 贴给 AI ，把基础设施仓库和项目仓库扔给 AI ，就等着结果了，k8s 的权限也给他了。

谁担责谁有权,谁有权谁担责

@defunct9 #11 这一套能管几个应用、几个集群呢，应用超过两位数估计就该忙不过来了吧。

.
├── docs
│ ├── cicd
│ ├── llm-platform
│ ├── logging
│ ├── monitoring
│ ├── openbao
│ ├── cluster-status.md
│ └── repo-review-2026-06.md
├── helm
│ ├── cert-manager
│ ├── clickhouse
│ ├── external-dns
│ ├── external-secrets
│ ├── jenkins
│ ├── langfuse
│ ├── litellm
│ ├── logging
│ ├── monitoring
│ └── openbao
├── k8s
│ ├── agent
│ ├── casdoor
│ ├── cert-manager
│ ├── clickhouse
│ ├── dashboard
│ ├── external-dns
│ ├── external-secrets
│ ├── gatus
│ ├── goalert
│ ├── jenkins
│ ├── langfuse
│ ├── litellm
│ ├── logging
│ ├── monitoring
│ ├── openbao
│ └── platform
├── AGENTS.md
└── README.md

发个大概的项目结构

不要看别人的发布流程，要看解决什么问题。小公司和大公司，小流量系统和大流量系统，能一样？

@fivesmallq k8s 权限直接给 ai ，有出过意外么，比如改了不该改的东西？我在使用中感觉 AI 有时候是傻，但不是坏，不会故意干坏事的

试试 argocd 吧，大家只管提交配置就能发布了。

以前的流程是

dev 提交 -> 触发 CI -> 单元测试 -> build Docker Image --> checkout helm chart env yaml --> 自动更新里面的 docker image --> 提交 helm chart

helm chart 提交触发 CD -> helm upgrade 更新 dev k8s 集群。

Prod 类似但是多了 review & approve 的过程

@Ayanokouji 不知道，不 care

@EthanWalkerTech 只使用 opus 4.8 或者 gpt 5.5

开发一个 paas 平台。
项目、资源、权限、CICD 、审计等等 管理平台

@EthanWalkerTech #25 nodeseek 溢价买的 BUG 鸡调防火墙被 GPT 玩崩，DD 后配置变了

内网是 jenkins 打 jar 包启动，开发就可以点击编译部署
外网是 k8s ，运维才能操作

上家公司是开发拉 git 开发，提交，然后走类似禅道的内部平台提交上线交付物清单，然后清单触发 jenkins 自动打包镜像，然后推送 dev paas 环境，测试验证没问题，推送到生产。上线当晚运维手动点击发布。上线当晚有问题，看能不能走 SQL 配置类修复，不行直接回退，第二天回来关禁闭写故障报告

发出问题了不得你背锅吗？

@EthanWalkerTech #10 是的，workflow 平台是我们做内部写中间件同学写的。分级审批的人员架构是基于钉钉拉取的组织架构和公司的 LDAP 做的结合

当时项目花了 2 周左右做了一套初版可用，随后让开发部门的一些同学来用做上线流程验证一周没问题后才全面对接开发业务同学让接入这套发布流程

https://flow.aliyun.com/ 阿里云流水线用起来

线上发布要走流程的，前后得一周。七八个人审核

Jenkins 正式环境只有运维和项目负责人能操作，非正式环境的人人都能上去操作