2020 年左右 .net core webapp 是可以很简单的在 ide 里生成 helm 部署到 k8s 集群的
但好像当时 go opreator 社区比较活跃
后来找了一段 devops ，跨度太大，感觉无望后也就没怎么关注 kubernetes 了
最近实践了 react native + c++ 的跨平台编程
写了一个 ios 和 android 上的扫雷游戏，win/mac/embeded linux/ios/android 都入门了
就差鸿蒙了 ，又有点《识盈虚之有数》的感觉
想再搭个 Kubernetes 高可用集群 玩一玩，看能不能做个聊天软件
刚才看有人在其他帖子的评论区讲提到 helm
思维发散了一下， 想看看有没有必要学一学 go, 毕竟 operator 是 go 模板
c++/rust/go 都能开发高并发服务，各有长短，前者有基础，后面两 0 基础，何当取舍？

你连话都说不明白， 一点逻辑都没有， 去知乎和 linuxdo 吧。

OP 是办公室怕被抓么，感觉都没怎么组织就啪啪啪打完发出来了

＃1 细嗦哪里没有逻辑？ 最近想玩 k8s->讨论有人讨论 helm-> helm 实用还是 operator 实用-> 要不要学 go ，以便写 operator 你串不起来吗？

＃1 还看不明白就告诉我，我给你理顺咯

wtf?

＃2 给你一个赞

不知道在说什么，一脸懵逼。
搭 k8s 高可用 玩一玩，跟你 做一个 聊天软件 两者有什么直接关系？
你要开发 operator ？ 你有什么 crd 需要定义？
谁 告诉你 operator 是 go 模板 这么笼统的总结的。

你又不了解，不会，你直接说，问问题就完事了。菜就承认

很少评论帖子，这是第一次 评价一个技术人，无语住了。（没忍住，不好意思，有点像一个知乎话题：为什么程序员这么自傲）

牛逼，我绕道了，拉黑不谢。

＃7 很正常吧，后端写成 helm 或 opreator 直接部署，否则为什么 ide 里要有这个功能呢，2010 年我就实践过了， 我确实不了解 operator ，但知道用 go 写 operator 是主流，我也确实是在问吧？

＃8 别太快拉黑，我给你点个赞再

我也是醉了，后端写成 xxx ，否则为什么要有 xxx 。
ide 跟前面的东西 有什么关联。你学技术 是根据 ide 的功能来学的吗？？？

请问 是不是 k8s 高可用没搭起来之前，你的 聊天软件 是不是 就不用写？

github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md

卧槽，牛逼，太专业了

＃11 自己玩的项目，肯定是先把环境弄好，一步到位吧，又不是公司项目，ide 里集成的功能说明是常用功能， 项目右键发布 heml ，不常用 做到右键里干什么呢

＃12 我确实有时要提 Iusse 看到一长串的模板就直接不提了，这是我的问题

确实没咋看懂你的问题是啥
如果你要做 k8s 运维开发工作，那 helm Opreator Go 都是绕不开的，可以看看我之前写的内容：
crossoverjie.top/2024/07/08/ob/how-operator-working/

一开始看着还挺正常，在讲 helm 和 operator 。
突然来了段“跨平台编程”，看到这里我就想这跟 k8s 有毛关系。
继续往下看，神奇的是楼主还能绕回来，又想搭个 k8s 高可用集群，结果刚起个头，又跑到”做聊天软件“上面去了。
没想到楼主只是虚晃一枪，继续聊 helm 和 operator ，让我猝不及防。
意识到楼主对 helm 和 operator 有深深的执念，正等他展开聊一下，结果还是上当了。
楼主以 c++/rust/go 如何取舍来结尾，发人深思，好文好文。

＃16 写得真好， 看来想水平弹性扩容，还是得 operator

＃17 不用这么严格朋友 和聊天一样就好

＃17 你的意思是聊天软件和 k8s 没有什么关系吗， 或者说这种技术组合不合理，我其实没做过后端，但很感兴趣，我认为 devops 是后端最终的方向

哪一年的，几岁了。同学

主流基础设施、平台组件基本都有成熟的 operator ，也就业务上可能会用到，真运维从来不纠结这玩意，会用就行了

＃21 为什么问年龄，重要吗，快 35 了

没明白在说啥

＃22 我的想法是写的后端 app 直接输出 docker 和 operator/heml ， 快速部署到测试环境或生产环境，一步到位

看不懂+1

首先 k8s 和聊天软件没啥关系，不懂为啥写“想再搭个 Kubernetes 高可用集群 玩一玩，看能不能做个聊天软件”，当然你可以写个聊天软件，愿意传统的部署方式就二进制/deb/rpm 部署，愿意容器化就 docker/k8s 部署，怎么舒服怎么来

其次想写 operator 也不一定非要用 go ，用 rust/python 也很成熟，一堆现成的轮子来用

最后作为一个 devops ，我对 operator 深痛恶绝（原因是这玩意儿太复杂了，研发的水平参差不齐，指不定写成什么样，我又不可能去替他们写或者 review 他们代码（我算哪根葱去审核他们代码)，写不好这就是个灾难），所以我都是要求我们的研发写 helm charts 来部署应用，而且一般研发也不会吃饱了撑的主动要求去写 operator

＃27

1. 聊天软件的服务跑在 k8s 用 docker 管理起来，不管是拉起测试环境，还是滚动更新，不是都更方便吗， 我觉得先搭 k8s 再部署后端程序很合理，为什么没关系呢
2. 2020 年进开发.net web app 可以在 vs 里右键快速发布为 helm ， 我理所当然觉得 operator 应该也有类似的工具，是我想简单了，

3. 我确定不知道其他语言能写 operator ，因为我 2020 年时看到里面大量用了[] go template 语法，既然其他语言也能写，那我会去了解一下，感谢指出

   ＃28 是跑 docker container 里，用 k8s 编排管理 containers ，你这个逻辑真的是混乱。

   ＃29 好的 你真讲究

   但凡 会 有点 AI ， 都问不出这种 憨憨问题。

   ＃18 「水平弹性扩容」和 operator 有什么关系吗？我认为没有半毛钱关系

   K8s 直接塞到 React Native 里讲，顺手把 DevOps 并发调到天花板。至于 Helm ，它在鸿蒙里玩高可用，其实跟 K8s 上一样能复用。怎么取舍？我觉得嘛，C++上的 K8s 得深挖才有味道，但游戏这种事，用 Rust 随便玩玩就行。

   ＃1
   ＃7
   ＃26

   ＃9 我要是你，我直接把这 2020 年的爷爷文档直接八米远

   高并发服务，得区分是 IOBound 还是 CPU Bound 的，我们 Gopher 从来没有承认可以开发 CPU Bound 的高并发服务。

   我感觉 他是 延边大神反串的。

   ＃32 说的是 helm 和 opreator operator 可以采集状态弹性伸缩

   ＃32 说的是 helm 和 opreator operator 可以采集状态弹性伸缩

   ＃31 万事求 ai ，这是不是太无聊了

   ＃33 手机上回复错了不好意思， 给你点个赞吧，这诗写得真好

   ＃35 这个你不说我倒不知道，对 go 一无所知，只知道 routine 又强又简洁，相对于 c++

   搭建 K8s 并学习 go 写 operator 完成部署聊天软件

   要提高表达能力，真的

   ＃43 脑子漫游状态，随便打了点字就发出来了，不知道什么时候养成了这么种习惯，打完最后一个字会直接发送出去 工作中日常交流没什么问题， 不过我觉得我没有跑题太多，
   1.提问了 helm 或 operator 的选择
   2.提问了几种并发语言 的选择

我看了你的几篇主题，都写得很有条理，我不行，恨不得多长十根手指，博客中也很多错字别错，也不是不认字，就是没有审核的习惯

＃34 没吃饭吗

楼主曾经对 k8s 有兴趣但是被 go operator 劝退了。

最近折腾了很多新玩意，感觉很有趣，就又想把 k8s 搞起来，但还是被 golang 难住了。纠结到底是学一下 golang 顺便把 helm 玩起来，还是投资到 rust 。

阅读理解速度比不上喷人的速度，还把 LinuxDo 和知乎带上，还一群人点赞。

＃38 我觉得 helm 和 operator 也没啥不然的关系。 你的意思是没了 helm 没了 operator ，k8s 这些能力就没了？

＃47 我是指，他博客中说的 helm 和 operator 的区别 ，不是说 k8s 没有它们不行

你的标题和内容有什么关系吗，k8s 的什么问题你倒是说呀？

＃49 你别急，明天再来刷新一下

我觉得楼主这段话的问题可能是干扰信息比较多，排版也没仔细整理过。又带上回帖里面大家火气又都重...

我看的意思是，楼主想用某个语言开发高并发的聊天软件并最终使用 k8s 部署，所以想问问用什么语言好，然后中间扩展了一些楼主目前的技术栈，然后怎么选的这几个备选的过程。

嗯...其实和标题确实关系不大，标题写“c++/rust/go 哪个更适合开发高并发服务”可能更容易理解？

＃51 helm 还是 operator 也很重要