我就纳了闷了，为啥总是看见 n 个一个环境就是一个 K8S 集群

2023-03-30 09:17:20 +08:00
 sampeng
做运维到现在 5 年多了。去一个公司以看就一个环境一个 k8s 集群。再进去看看，一个业务 namespace+一个 kube-system 。
上一个东家。20 个集群。每个集群 20-30 个 pod ，线下物理机
现在这一家。我进来的时候 15 个集群。每个集群不到 10 个 pod 。而且是云上。最近被我干掉只剩 6 个了，一个产品一个环境一个。线上和 staging 的不是太好动，得找时间找机会做迁移。

应该不是我运气背，感觉是个普遍线上。难道学 k8s 得都是不知道亲和性和节点选择器的？这是偷懒还是就是懒得学?我说我一面是基本都是 yaml enginer 。也就会写个 deployment ，svc 之类的。再问细点就一问三不知了。比如 requests 和 limit 的区别，问 10 个 9 个答不出来。。

不是，k8s 的官方文档就在那放着啊。好歹看看最基础的字段是干嘛用的吧？
6443 次点击
所在节点    Kubernetes
54 条回复
dreamramon
2023-03-30 10:57:18 +08:00
肯定要隔离啊，测试环境如果给你搞点活，一下把生产的资源都给你占满了，如果造成了损失，谁来买单。。。
sampeng
2023-03-30 12:49:16 +08:00
@rrfeng 对啊…我也是这么干的…一个配置而已…再不济辛苦点，每个服务写一下亲和性
sampeng
2023-03-30 12:50:05 +08:00
@coderxy 不要拿无知质疑别人的做法。这是官方插件只是再低版本下没启用
sampeng
2023-03-30 12:56:26 +08:00
@swulling 您解释得挺好得，我也比较同意在你这个语境下得情况。

只是大多数就一个团队，研发也就十来个人。谈不上管理控制面。而且现在大把得开源 or 收费得 dashboard 解决方案。接入 ad 或者账号系统就解决了。namespace 方案对于运维而言是友好得。多一个集群多一个维护成本。而且资源利用率低得发指
sampeng
2023-03-30 12:58:34 +08:00
@rrfeng 云端可能没启用这个插件。我机房得是启用了得。。那是相当得舒适。其实就是自动修改 pod 得亲和性。自己得空写个注入得 webhook 也能实现
sampeng
2023-03-30 13:02:42 +08:00
@fengye0509 还真有好说得。仅仅是资源请求和限制？多少请求是合适得，多少限制是合适得。怎么通过数据来体现。request 和 limit 转换成 docker 在宿主机看起来是怎么一个限制逻辑？ request 为什么不能超过 100%。limit 反而可以？数值大小是否影响调度。

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

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

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

哦。阿里云得也有，我想起来了。一时半会找不到了
sampeng
2023-03-30 13:14:25 +08:00
@dolphintwo 也是。。又不是不能用
pepesii
2023-03-30 13:24:32 +08:00
如果没有专门的人来运维 k8s 集群，不把鸡蛋放一个篮子也是一种选择。如果 k8s 本身的某些组件挂了，在这种情况下，影响能降低到最低。
老板不要求降本增效，研发团队用的舒服就行，合适的，就是最好的。
sampeng
2023-03-30 13:59:02 +08:00
@pepesii 同意你的观点，从这个角度出发时 ok 的
iloveayu
2023-03-30 14:05:40 +08:00
是这样的能跑就行，需要请专业运维来做事时，一定是他们的 infra 已经一坨屎，开发自己搞不定了。
rrfeng
2023-03-30 14:54:21 +08:00
@sampeng 看起来是原生支持的
swulling
2023-03-30 15:44:28 +08:00
@sampeng 嗯，租户=Team

一个 Team 在同一个 Region 的同一个 Stage （比如生产）最好只有一套环境
chronos
2023-03-30 15:45:13 +08:00
我一般生产环境的强隔离上单独的集群。至于开发和测试环境嘛，能省则省，资源共用，用 namespace 做逻辑隔离，配合亲和性和 request 、limit 处理就行。
xuanbg
2023-03-30 15:53:51 +08:00
生产环境肯定是要独立的吧？测试和开发我们是一个环境。所以，我们就两个集群。不管什么业务，都往一个集群里面怼。要辣么多集群做什么，平白无故占用资源，而且管理起来也麻烦。
optional
2023-03-30 16:51:18 +08:00
按照一台物理服务器 10w ，10 台也就 100w 的预算，还要按照三年或者五年折算。现在一个高级的开发，一年至少 100w 的预算，10 个就是 1000w 。 数据的价值更难以衡量，你觉得统一大集群的好处是什么
optional
2023-03-30 16:53:07 +08:00
至于运维的成本，维护最好自动化脚本，发布做好 cicd ，再加上监控，多几个集群，运维没多少工作量的。
57L49t45Jo9IJvge
2023-03-30 17:06:05 +08:00
纠结这些干啥 线上稳了 其他都是浮云
salmon5
2023-03-30 17:42:18 +08:00
一个大产品线，严格的，dev,qa,stag,prod 4 套集群
宽松的，dev-qa-stag,prod ，2 套集群
也有业务维度分，某些团队专用集群，这个都是合理的，
当然 RBAC 可以控制，但是 RBAC 沟通成本高
salmon5
2023-03-30 17:44:15 +08:00
成本的维度，集群本身成本还好，node 成本高

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/928362

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX