@matrixji 嗯，类似。也跟 Operator Framework 有很大关系。赶紧来搞。

@matrixji 大概率是 HC 被关闭了吧，建议重新来一波。

P8-P9 候选人对这个方向感兴趣，欢迎发邮件或者直接加微信（ resouer ）详细聊。

@NoobPhper 没有的哈

@JsonBruce 3 年起

@impl 你现在能找到不玩 K8s 的知名技术公司吗？

@daryl 想去就投啊，跟大家多沟通也互相进步

@matrix1986 是 K8s 生态项目，不是 K8s 源码本身，可以来试试

@hhyvs111 2020 年的应届生麻烦看这里： https://www.v2ex.com/t/590631#reply6

@wei28 直接给简历，不要套近乎

@polebug 对，docker 和 k8s 的使用经验不重要哈

@bokchoys 全世界几乎所有的技术公司都在用 k8s ...

@wqsfree 那说明你没来我们这种把 intern 当上帝的团队 ……

@recall704 可以试一下 https://v3.helm.sh/docs/using_helm/#installing-helm

@ps1aniuge 这里理解有点偏差，Helm 重点解决的是应用定义和打包的静态问题，Operator 解的是有状态应用怎么部署运行升级的动态问题。当然，现在 Helm 有点想往后吃动态的部分，做的很差。关于 Operator 的沿革和未来，以及它和有状态应用的关系，不知道有没有读过我们之前的这篇文章： https://www.lijiaocn.com/%E9%A1%B9%E7%9B%AE/2019/01/08/kubernetes-api-and-operator-history.html

@monsterxx03 感谢分享，你们的这个 workflow 感觉很典型

@Ley 对的，我们目前对 Helm 的用法，就是只把它当包管理使用，后面的流程都是 kubectl

@sampeng v3 没有 tiller 了，但我们觉得 Helm templating 实际上问题也不小

@twl007 生成出来的 patch 多还好吧，我们通过 Git 组织起来， 不过看起来缺失一个面向 Git 的应用管理工具来操作这些 patch。另外我其实觉得生成 Patch 的过程比较难弄，感觉少一个像 Dockerfile 这种的文件。。。