共计 2785 个字符，预计需要花费 7 分钟才能阅读完成。
前 言
Rancher 作为一个开源的企业级 Kubernetes 集群治理平台。你能够导入现有集群，如 ACK、TKE、EKS、GKE，或者应用 RKE、RKE2、K3s 自定义部署集群。
作为业界当先的多集群治理平台，Rancher 能够同时纳管上千个集群和上万个节点。同时，大家也不用放心运维治理大规模集群和节点会减少额定的累赘，社交通信软件 LINE 5 集体就足以治理 130 个集群的 2000 个节点。
如何在 Rancher 中治理大规模的集群和节点这次暂且不谈，之前曾经介绍过很屡次了。明天咱们只聊如何在单个集群中治理大规模的我的项目、命名空间等资源。
如何在单个集群中治理大规模的我的项目和命名空间
- 命名空间：命名空间是 Kubernetes 的一个概念，它容许在一个集群中建设一个虚构集群，这对于将集群划分为独自的“虚构集群”很有用，每个虚构集群都有本人的访问控制和资源配额。
- 我的项目：一个我的项目就是一组命名空间，它是 Rancher 引入的一个概念。我的项目容许您将多个命名空间作为一个组进行治理并在其中执行 Kubernetes 操作。您能够应用我的项目来反对多租户，例如设置团队能够拜访集群中的某个我的项目，但不能拜访同一集群中的其余我的项目。
从档次上来说，集群蕴含我的项目，我的项目蕴含命名空间。如果把公司了解成是一个集群，那么我的项目对应的就是部门或者团队，咱们能够给某个部门或者团队针对不同的我的项目去划分权限来治理多个命名空间。
所以，咱们在生产环境中会创立大量的我的项目和命名空间，那么如何布局这些我的项目和命名空间呢？
倡议我的项目依照部门或者团队去划分，针对不同的我的项目授予相干访问控制
每个我的项目内具备不同目标的环境应用命名空间去隔离，例如：生产环境和测试的环境
为了验证在 Rancher 单集群中具备治理大规模我的项目和命名空间的能力，咱们在一个集群中创立了 500 个我的项目，并且在每个我的项目中创立了 10 个命名空间，最初，在每个命名空间创立：1 个 Deployment、2 个 Secret、1 个 Service、2 个 ConfigMap 来模仿实在场景下的应用。
以下是测试集群规模：
这样咱们在单集群中创立了共计：500+ 个我的项目、5000+ 个命名空间、5000+ 个 Deployment/pod、10000+ 个 ConfigMap、10000+ 个 Secret 和 5000+ 的 Service 的资源。
接下来，咱们来体验通过 Rancher UI 来治理这些资源：
首先登录 Rancher UI，因为只有一个集群，无论集群下有多少资源，都不会被加载，所以加载速度和一般规模集群无差别
当我的项目十分多时，咱们能够在搜寻框疾速定位到咱们须要查问的我的项目：
进入到某个我的项目，1.5 秒 左右即可实现加载
接下来咱们来创立一个 Deployment，从后果来看，和一般规模的集群的加载速度无区别
其余的资源的治理就不给大家一一展现，测试后果和一般规模集群的加载速度简直统一。从以上的场景剖析，单集群蕴含大规模我的项目、命名空间等资源并没有给 Rancher 带来太大的性能压力 。
因为测试环境主机资源无限，这次验证只创立了 5000 个 deployment，只有正当的分配资源到我的项目，置信再多几倍的资源规模应用 Rancher 治理也会十分轻松。
一个不倡议的场景
尽管是不倡议的场景，但还是要阐明，防止大家在单集群中治理大规模我的项目和命名空间时踩坑。
十分不倡议大家将所有的资源都沉积在同一个我的项目中，就比方将 5000+ 个命名空间都放在同一个我的项目中。
为什么不倡议呢？简略来说，从 Rancher Cluster Manager 上进入到某个我的项目时，会加载我的项目中蕴含的所有资源。我的项目中蕴含的资源越多，加载我的项目中资源的速度也会随之变慢，如果数据量特地特地宏大，有时候会呈现 timeout 的状况。而 Rancher 治理立体是通过 cluster tunnel 与上游集群的 API 通信，如果资源数量过于宏大，这条 websocket tunnel 的累赘会很重。
尽管不倡议大家将所有的资源都沉积在同一个我的项目中，然而并不代表在 Rancher 中没方法治理这种场景。如果在你的生产环境中必须将所有的命名空间等资源放在同一个我的项目中，而且数据量十分宏大。那么举荐你应用 Rancher v2.5 新增的 Cluster Explorer，Cluster Explorer 针对单个我的项目中加载资源进行了优化，简直不会呈现 timeout 的状况。
下图展现的是在 Cluster Explorer 的同一个我的项目中加载 3000 个命名空间、3000 个 Deployment、3000 个 Service、6000 个 ConfigMap、6000 个 Secret 的示例：
由此可见，通过 Rancher 2.5 的新 Dashboard，Cluster Explorer，也可能在单个项目管理上千个资源。
大规模集群治理调优倡议
作为一个多集群的治理平台，无论是集群数量的增长还是单个集群 workload 数量的增长，都会对治理立体造成肯定性能挑战。所有组件的默认参数是罕用规模的最佳的产品配置，而面向大规模场景，局部平台参数甚至零碎内核参数都须要进行调优，以便治理立体的外围能够获得最佳性能。
用户可依据本身的应用规模来采取相应的优化计划，所有的优化措施并不是必须的，须要针对本身的场景“因地制宜”。Rancher 的默认的配置参数曾经是绝大多数应用场景的最佳计划，如果是治理大规模集群，则须要调整相干配置，以下是一些大规模集群中的一些常见优化参数：
针对治理立体大量的 TCP 连贯，从 OS Kernel 层面进行优化，已尽量施展硬件配置的最佳性能。常见配置及其性能阐明如下：
以下参数属于集体总结，仅供参考
Kernel Tuning
Kube-apiserver
针对原生资源和 CRD 的 API 的并发能力与缓存优化，晋升 API List-Watch 的性能：
本文的重点不是调优，所以只介绍一些罕用的参数，更具体的参数 (例如：kube-controller-manager、kube-scheduler、kubelet、kube-proxy) 阐明还请大家参考 Kubernetes 官网。
后 记
从以上验证后果来看，Rancher 具备在单个集群中治理大规模我的项目和命名空间的能力，只有正当的应用正确的形式搭建集群和部署业务，就不会对 Rancher 带来太大的压力，也不存在性能问题，同时也要依据集群规模来调优主机和 Kubernetes 参数，使其施展出最佳性能。
作者介绍
王海龙，SUSE Rancher 社区技术经理，负责 Rancher 中国技术社区的保护和经营。领有 6 年的云计算畛域教训，经验了 OpenStack 到 Kubernetes 的技术改革，无论底层操作系统 Linux，还是虚拟化 KVM 或是 Docker 容器技术都有丰盛的运维和实践经验。
