当用户更新 k8s 资源时，我发现有更新操作就去更新一遍资源以达到覆盖用户更新的目的。
这个不就是 Admission Control 做的事吗，感觉你技术选型错了

有 2 个可能：
1. nodeport 这里有网络损耗，可以通过将 pod 设置为 host 模式排除
2. pod 里面有写文件系统的读写操作，导致有 IO 瓶颈，可以通过使用 hostpath 来排除这个问题

gpt3.5 好像是有 4096 个 token 长度限制，遇到截断最好是新开一个会话，“继续”的效果并不好。

性能方面，如果数据库的数据是存放在 pvc 中的，而 pvc 的后端是腾讯云或者阿里云的云盘，那 IO 这块也没什么损耗，跟你在虚拟机上挂个云硬盘性能差不多。所以我觉得数据库运行在 k8s 中相比于直接运行在虚拟机上在公有云的场景下不存在什么性能问题。事实上我们公司的生产环境数据库早已经运行在 k8s 中了。
运维方面，部署在容器和虚拟机上差别还是很大的，很多 dba 可能都还不太适应。
长远来看，我认为会有越来越多的公司选择把数据库（有状态服务）运行在 k8s 中。DBA 也会越来越习惯于运维容器中的数据库。

好奇问一下，做这个项目的出发点是啥，现在市面上已经有不少类似的成熟平台了

@documentzhangx66 谁告诉你放容器数据会丢的，现在都是通过 pvc 做数据持久化，在公有云上，一个 pv 其实就是一个云硬盘，性能跟虚拟机的硬盘是一样的，而且也几乎不存在丢的情况

@vibbow 有状态应用云原生化是现在的大趋势，很多中间件和数据库都在针对云原生化做存算分离的调整。
拿 mysql 来说，上到 k8s 之后，部署的一致性与便捷性对运维和开发人员来说都是好事。除开对运维人员的要求更高以外，也没什么其它弊端，当然没有必要为了上 k8s 而上 k8s ，上不上还是要根据自己的业务场景，能不能解决问题来权衡。

@sodayo 最近在研究这下，好奇你们用下来体验如何，有没有什么痛点问题

现在的顶楼，很多会铺一层很厚的土，然后种上草，我就是买的顶楼，一点都不热，相反，因为顶楼风比较大，非常凉快。

我们在用万里的 greatsql

@ydongd 域名解析不说了，网络打通给你个关键词 calico bgp

两个步骤：
1. 在集群外解析 headless service 域名地址
2. 将 clusterIP 与集群外网络打通

agent 之间不建议做共享，会有坑

rocketmq 感觉是有点随意，配置项都是用 brokerIP1,brokerIP2 这种命名的。。。

@hooopo 因为你不备案，按照大陆目前的法律，你是无法在大陆地区运营的

这年头，这种社区搞不起来，备不了案

深有体会，我之前的房子就是因为这个原因卖了，然后现在买了一个顶楼

把 pod 的优雅退出时间设置长一点？当然，你的应用要能捕获到退出信息，以便尽快结束当前正在处理的任务

envoy