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

没看懂在说什么。。一个业务一个 namespace 我觉得很正常啊，和亲和性有什么关系。。

可能是为了隔离吧，dev/prod 如果混用同一个集群，万一互相访问了就糟糕了

确实感觉很多东西都是半懂不懂的人弄出来的 先弄出来用 用着用着就成了事实状态了 改也不好改

1. 懒；
2. 不同的业务或者产品线用不同的账号来控制权限或者账单，自然就不能用一个集群
3. 某些客户有数据安全性的要求

感觉至少 80%是 1

开发环境或者测试环境你迁移也算了
线上环境你还准备找机会迁移,迁移成功了是分内的事情,没有什么好处,一旦线上环境出大问题,严重的话就直接把你开除了

同意 LS ，你问过你领导么 说迁就迁。。。这不好吧

@james2013 工作量啊，那你我把原来混乱的局面改变了，是不是得升职加薪了了，哈哈
统一化是一门大学问

不懂就问，这样搞好多集群的缺点是什么？

我觉得你的表达能力有待提升

感觉很多时候都是老板要求强上的…

Kubernetes 的多租户本身就有两种方案：多命名空间和多集群。

其中因为 K8s 自身在多租户和权限控制方面做的其实不是很好，普通公司没有办法自己搞一套管理面，所以不如多集群方便。

而多集群方案又分为：

- 共享控制面方案：apiserver/scheduler/controller-manager 统一部署，每个集群只有 node 是单独部署的，node 可以直接购买 VM 。好处是节约控制节点资源，计算节点资源隔离

- VirtualNode 方案：为了解决 node 独占带来的资源浪费，使用共享控制面 + VirtualNode 。这种方案也是我认为在云上最好的方案。同时也可以结合独占 Node ，特别灵活。

- ClusterInCluster：搞一个母集群，然后虚拟出多个子集群（每个 namespace 虚拟出一个子集群），好处是子集群之间可以共享节点，提高资源利用率。


如果一年前，我支持多 namespace 方案，但是现在，我支持多集群方案。

另外补充下，K8s 的部分资源其实是全局的，多 namespace 方案很麻烦。

想要物理隔离呗，故障区域减小。

话说 node 要是可以绑定 namespace 就好了。

@rrfeng node 不能绑定 ns ，但是 node 可以设置亲和性，然后给某个 ns 的 pod 都设置某个亲和性标签，就能实现这个 ns 的 pod 都在某几个 Node 上了

@coderxy 我们就是这么干的，但是如果 ns 能够自动完成这个事情不是更好么。

隔离啊，至少测试 /线上肯定要分开啊，光节点隔离又不完全，测试环境给你整点活，把集群负载搞卡了也不是不可能发生，版本升级也能拿小集群先升级看看。

如果不根据环境拆集群，测试环境想要升级 K8S 版本难道要把生产环境的节点组也一同升级？ 万一因为验证测试新特性，然后出现 CoreDNS 或者 CNI Network 故障，也是一并把生产环境带崩？

@rrfeng 你可以给 k8s 提 PR 哈哈。 不过一般来说有亲和性已经够了，而且亲和性更灵活。

你就说能不能用吧

requests 和 limit 有什么好说的，资源请求与限制，多环境多集群不是很正常吗？ ns 区分项目
节点亲和性可以用大节点跑重服务，反亲和性可以用来限制多个 pod 跑在同一节点

肯定要隔离啊，测试环境如果给你搞点活，一下把生产的资源都给你占满了，如果造成了损失，谁来买单。。。

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

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

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

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

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

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

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

@rrfeng

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

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

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

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

如果没有专门的人来运维 k8s 集群，不把鸡蛋放一个篮子也是一种选择。如果 k8s 本身的某些组件挂了，在这种情况下，影响能降低到最低。
老板不要求降本增效，研发团队用的舒服就行，合适的，就是最好的。

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

是这样的能跑就行，需要请专业运维来做事时，一定是他们的 infra 已经一坨屎，开发自己搞不定了。

@sampeng 看起来是原生支持的

@sampeng 嗯，租户=Team

一个 Team 在同一个 Region 的同一个 Stage （比如生产）最好只有一套环境

我一般生产环境的强隔离上单独的集群。至于开发和测试环境嘛，能省则省，资源共用，用 namespace 做逻辑隔离，配合亲和性和 request 、limit 处理就行。

生产环境肯定是要独立的吧？测试和开发我们是一个环境。所以，我们就两个集群。不管什么业务，都往一个集群里面怼。要辣么多集群做什么，平白无故占用资源，而且管理起来也麻烦。

按照一台物理服务器 10w ，10 台也就 100w 的预算，还要按照三年或者五年折算。现在一个高级的开发，一年至少 100w 的预算，10 个就是 1000w 。 数据的价值更难以衡量，你觉得统一大集群的好处是什么

至于运维的成本，维护最好自动化脚本，发布做好 cicd ，再加上监控，多几个集群，运维没多少工作量的。

纠结这些干啥 线上稳了 其他都是浮云

一个大产品线，严格的，dev,qa,stag,prod 4 套集群
宽松的，dev-qa-stag,prod ，2 套集群
也有业务维度分，某些团队专用集群，这个都是合理的，
当然 RBAC 可以控制，但是 RBAC 沟通成本高

成本的维度，集群本身成本还好，node 成本高

当然也看有没有容器 infra 的人力投入，没有容器 infra 人力投入，怎么省事沟通成本低怎么来

看你的描述，感觉之前是通过不同集群部署不同服务，降低运维风险； 集群可以按需升级，很传统，很 vm 的感觉

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

想知道你们的集群一般几个机器，机器的配置是怎么样的，pod 的内存和 cpu 一般是根据什么原则分配的? 资源的利用率能达到多少？

什么能力的人搭配什么公司的技术,没毛病

你这都不算啥，我司 100+个集群你敢信？

借楼请教下，rd 想转运维，大佬们指导下路径？

下次发长文前找 ChatGPT 润色一下

@sampeng 那你做的很对啊，这明显的降本增效，大哥们没给发奖金么

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


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


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

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

最近也因为 requests 和 limits 吃了个大亏，一个开源的区块节点，资源推荐 16C 16G ，然而我 requests 和 limits 按照这个配置后，导致整个服务器 load 直接飙到 600 多（物理机 64C ，256G ），机器直接 hang 住卡死。后面放开 CPU 的 limits 和 requests 就没事了。

@Aumujun 为什么放开就能没事？ 能详细讲讲吗

@leopod1995 我怀疑是程序需要大量使用 CPU ，但被限制导致等待 CPU 的任务越来越多，然后 load 越来越大，最后 hang 死服务器；当然这只是我的猜测，但放开 cpu 后确实没有再出现，已经观察有四天了。