作为有幸回湖南长沙出差的人来说，北京没有早餐没有夜宵没有夜生活…

反正北京晚上晚于 9 点基本没什么好吃的了，全是烧烤快餐一类的。

长沙，晚上 2 点酒店饿了下楼随便吃点…

楼上没必要无脑黑吧，GPT 本来就是开源的模型 openai 只是没开源源码而已。
哦，是 csdn 搞的？如果是套的壳他要么所以花钱做的 Api ，要么就是 web 方式用 token ，哪位大侠写个脚本…刷爆公司信用卡轻轻松松吧…

当然感觉不是，首先这玩意是被墙的…以公司名义翻墙不需要做关键词测试，本身就是违法的

有。喂本地资源做自己的知识库必须得是本地的

@zhuantouer 借楼回复，别了。大环境并不好。

@Nnq 有啊，中午吃饭加个鸡腿


@LaurelHarmon 确实是随性而写，我自己都没读通顺…


@saltbo 我草…除非有完善的运维平台，控制面和遥测体系。运维噩梦🤔

@Nnq yes..这是正解。这两个都是之前是 vm 的机器跑服务。迁移到 k8s 还是按这个逻辑去搞

@pepesii 同意你的观点，从这个角度出发时 ok 的

@dolphintwo 也是。。又不是不能用

@rrfeng

是上家公司得时候配得，就没找到配置了。是根据这个上面提到得插件。开启一下就好了。。。

https://stackoverflow.com/questions/52487333/how-to-assign-a-namespace-to-certain-nodes

哦。阿里云得也有，我想起来了。一时半会找不到了

@fengye0509 还真有好说得。仅仅是资源请求和限制？多少请求是合适得，多少限制是合适得。怎么通过数据来体现。request 和 limit 转换成 docker 在宿主机看起来是怎么一个限制逻辑？ request 为什么不能超过 100%。limit 反而可以？数值大小是否影响调度。

当然我一开始也是不懂得。。。后来我们做了一个功能，要晚上重建环境。删除所有的 pod 。白天再启动起来。因为对 request 和 limit 得理解不到位。100 来个 java 得 pod 启动瞬间直接干死几台物理机。狠狠得补了一下课

@rrfeng 云端可能没启用这个插件。我机房得是启用了得。。那是相当得舒适。其实就是自动修改 pod 得亲和性。自己得空写个注入得 webhook 也能实现

@swulling 您解释得挺好得，我也比较同意在你这个语境下得情况。

只是大多数就一个团队，研发也就十来个人。谈不上管理控制面。而且现在大把得开源 or 收费得 dashboard 解决方案。接入 ad 或者账号系统就解决了。namespace 方案对于运维而言是友好得。多一个集群多一个维护成本。而且资源利用率低得发指

@coderxy 不要拿无知质疑别人的做法。这是官方插件只是再低版本下没启用

@rrfeng 对啊…我也是这么干的…一个配置而已…再不济辛苦点，每个服务写一下亲和性

公有云用什么，我就用什么。怎么着？你还有得选？

ceph 真的已经是简单到爆炸了的东西。。。只要你肯大力出奇迹。就不会出问题。
比如我上一家,大力出奇迹。两台 dell 的 40T 磁阵。10 台服务器。组成一个 ceph 集群。并且是光交相连所有设备。再来 36 台的 16c64G 的服务器当 k8s 服务器。稳如泰山。2 年到我离职我都没去碰过他，全程默认值。最后一看，也就用了 10T 不到。。也就 2000 来个 pod 吧

数据库你放 k8s ？是想学死字的 n 种写法吗？
云端也尽量不要放在 k8s 里啊。虽然他可以漂移。你线上环境飘一个试试看？

最大的卡脖子居然没说，在这扯技术…
哪来的 gpu 算例啊…

@Chihaya0824 也不认识了…都是一本正经胡说八道