我有点担心楼主的流量费用

打卡

升级之后我的 istat 显示的网络下行速率一直是 0 了

鹿岛值得拥有

我想怎么国内怎么看 tiktok

我们一般用 rancher 的 rke

工作：IT 荒漠
生活：相当安逸

mysql 不同操作的 IO 模型不一样，脱离 IO 模型谈并发，没有意义

@Ericcccccccc red hat 这样做是违返 GPL 协议的，所以不可能不公开代码

深有同感，看怎么选择，要稳定的话，还是国企会好一些。在国企就不要整天想着技术问题了，也不要去关注怎么实现落地，逻辑上说得通，能吹就行

有意思

当用户更新 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 最近在研究这下，好奇你们用下来体验如何，有没有什么痛点问题