共计 3733 个字符，预计需要花费 10 分钟才能阅读完成。
源起
知乎是中文互联网高质量的问答社区，每天有上千万用户在知乎分享常识、教训和见解，找到本人的答案。为配合不同阶段的业务倒退需要，知乎容器平台也在一直演进、晋升，目前简直所有的业务都运行在容器上。
这两年知乎开始应用 Rancher 治理 Kubernetes 集群，集群规模逐渐达到近万节点。本文将介绍 Rancher 如何针对大规模集群进行性能调优，最终访问速度晋升 75%，达到页面拜访体验可用的状态。
对于为什么会抉择 Rancher 作为咱们的容器治理平台，大抵起因有以下几点：
咱们的业务部署在国内多家私有云 Kubernetes 上，须要对立的平台来治理这些 Kubernetes 集群，而 Rancher 针对国内的私有云 Kubernetes 平台兼容性十分敌对。
Rancher 升高了 Kubernetes 集群的部署和应用门槛，咱们能够借助 Rancher UI 轻松纳管和应用各个 Kubernetes 集群。不是很深刻理解 Kubernetes 的研发同学也能够轻松创立 Deployment、Pod、PV 等资源。
咱们能够借助 Rancher Pipeline 在外部实现 CI/CD，使研发专一于业务利用的开发。只管 Rancher 团队告知 Pipeline 曾经进行保护，然而它的简洁仍然合乎咱们外部对 CI/CD 的定位。
Rancher 的继续创新能力，还有围绕着 Kubernetes 进行了一系列的生态扩大及布局，比方：轻量级 Kubernetes 发行版 k3s、Kubernetes 的轻量级分布式块存储系统 Longhorn、基于 Kubernetes 的开源超交融基础设施 (HCI) Harvester、以及 Rancher 的下一代 Kubernetes 发行版 RKE2。追随头部翻新厂商，对团队的继续提高也是大有益处。
Rancher 作为国际化的容器厂商，在国内有十分业余的研发团队，沟通交流十分便捷。很多问题都能够在 Rancher 中文社区中找到答案，对于开源且收费的平台来说，能够说是十分良心了。
迷局
起初，咱们在应用 Rancher 治理中小规模集群时，RancherUI 提供的性能简直能够满足咱们所有的需要，并且 UI 也十分晦涩。
但随着业务量的减少，集群规模一直的扩充，当咱们扩充到应用 一个 Rancher 治理近十个集群、近万节点和几十万 pod 时（单集群最大规模将近几千个节点和数十几万 pod），操作 Rancher UI 频繁会呈现卡顿并且加载工夫过长的问题，个别页面须要 20 多秒的工夫能力实现加载。重大时可能会造成连贯不到上游集群的状况，UI 提醒“以后集群 Unavailable，在 API 准备就绪前，间接与 API 交互性能不可用。”
没错，咱们碰到了 Rancher 的性能问题。尤其是超级管理员用户，登录时须要加载的数据量较大，基本上 UI 处于一种不可用的状态，上游集群也断连频繁。
破晓
从下面的景象来看，应用 Rancher 治理超大规模集群仿佛遇到了性能问题，影响了应用体验。随后寻求 Rancher 外乡技术团队帮忙，通过几次高效的线上会议沟通，根本找到根本原因：
- 尽管咱们的集群数量不多，然而所有集群节点总量并不小。页面加载时，依赖 node list 接口获取数据（此 node 为 Rancher 创立的一种非凡 CRD，它与理论上游集群的节点数无关），该接口解决工夫较长，引起页面加载迟缓。
- 咱们的上游集群中，次要以私有云的 Kubernetes 为主，这些集群通过导入形式纳管到 Rancher 中。这种纳管模式下，Rancher Server 通过与 cluster-agent 建设的 Tunnel，拜访上游集群的 Kube API，然而这里并非间接拜访，而是走 Tunnel 到 Kubernetes Service IP 拜访（如 10.43.0.1:443）最终负载到多个 Kube-api server。通常这种模式并没有问题，然而因为咱们的访问量和数据量都比拟大，SVC IP 转发能力无奈撑持，重大影响了通信效率。
经理解，如果要通过社区版解决该问题，操作会相当简单。但企业版 Rancher 曾经针对性能优化有了一套成熟的计划和策略，以下是 Rancher 工程师介绍的对于企业版和社区版 Rancher 的区别：
企业版和社区版 Rancher 针对查问资源最次要的区别在于：针对一些慢查问 API，社区版是通过 Kubernetes API 读取数据，企业版通过 Cache 中读取。同时，反对多种上游集群的连贯策略，从而晋升和上游集群的管理效率。另外，企业版还对监控 / 日志 /GPU/ 网络等基础设施能力有肯定加强，并且对外乡商业客户的 BUG 响应上会更疾速。
出于国情须要，企业版是一种非凡的存在。海内客户根本只能订阅开源版本，外乡客户能够额定享受企业版的个性，并且企业版是齐全外乡研发团队开发。秉承 SUSE Rancher 的凋谢理念，用户能够来去自如，企业版与开源版之间随便切换。
针对以上剖析，咱们通过衡量，决定临时应用企业版对集群进行调优实际。
抉择
切换到企业版
首先咱们从社区版 Rancher 切换到了企业版，企业版的迭代偏稳重一些，发版策略不会严格遵循开源版。好在咱们应用的社区版有对应的企业版版本，并且反对从社区版平滑切换到企业版。基本上是无损切换，间接替换镜像即可，相当不便。
优化上游集群参数
Rancher 工程师举荐了一些上游 Kubernetes 集群的参数优化计划，不过咱们对自定义 RKE 集群应用不是很多且次要以私有云 Kubernetes 为主，这种上游集群组件参数的优化和理论的环境相干，这里只列出了一些比拟罕用的 kube-apiserver 参数作为参考：
内核调优
Rancher 团队也给咱们提供了一些开源社区比拟成熟的调优参数：kops/sysctls.go at master · kubernetes/kops · GitHub（https://github.com/kubernetes…）
开启资源缓存
开启资源缓存后，一些波及读取 Local 集群数据的接口，将会走 Cache 模式，极大晋升 API list-all 的性能，针对咱们环境中节点数特地多的场景有显著成果。目前减少了缓存的资源如下：
集群连贯模式
企业版中针对连贯上游集群的形式进行了优化，并且反对多种连贯上游集群的形式，企业版用户罕用的连贯策略包含：
策略一：默认配置
默认策略，就是不批改连贯形式，沿用社区版连贯上游集群的策略。
企业版中默认 Tunnel 中的 k8srest client 的 timeout 值为 60s，能够无效缩小 heavy load 时上游集群数据查问的失败几率，性能晋升无限，然而申请成功率会有很大晋升。
策略二：优化 Tunnel 链路
默认状况下，通过 Tunnel 应用上游集群的 Kubernetes API Service（如 10.43.0.1）进行通信。如果自建集群的内部，有一个性能更好的 Kubernetes API LB，能够将连贯上游集群的 apiEndpoint 改为 LB 入口地址，这样能够通过 Kubernetes API LB 分担压力，晋升连贯上游集群的速度。
策略三：间接和 Tunnel 双链路
启用直连和 Tunnel 双链路模式之前，须要确保上游集群有一个从 Rancher Server 网络间接可达的 apiEndpoint（参考策略二）。优化后，Rancher API 中针对上游集群申请的 v3 接口走直连，其余还是走 Tunnel，这样能够无效扩散流量，防止大量数据都在 Tunnel 中传输。绝对策略二，性能进一步失去晋升，然而比拟依赖根底网络布局。
最终，咱们抉择了“策略二”去连贯上游集群，因为咱们有一个性能弱小的 KubernetesAPI LB。当切换连贯上游集群的链路会呈现短暂的上游集群不可达的状况，但不会影响上游集群的业务运行。
硕果
首先，Rancher 企业版 UI 对于咱们团队来说非常不便，左侧导航栏能够轻松找到各种性能，适宜国人的应用习惯。可能是咱们从事基础设施治理的缘故，对这种极简 UI 格调能够说是十分喜爱。
其次，通过上述策略优化后，晋升了 Dial Kubernetes API 时的 Timeout，最终简直看不到因超时导致的申请失败。另外，应用上游集群的 Kube api-server 的 LB Endpoint 作为申请指标，上游集群断联景象曾经隐没，堪称从村道换成了高速公路。** 此外，反对局部接口通过缓存疾速检索，尤其对于 Node 资源，从 20+ 秒的响应工夫缩短至不到 5 秒。其余比拟重要的接口也进行了比对，平均速度晋升了大略 75% 以上。
在 Rancher 企业版中，用户能够通过优化上游集群的参数、设置连贯上游集群的策略、开启缓存等形式来大幅度优化集群性能，进而轻松治理大规模集群。从上述实际能够看到，只有正当的做好调优和布局，即使是像知乎这样超大规模的集群，也能和小规模集群有一样的应用体验。
本文撰写时，Rancher 外乡团队正在对企业版性能做二次调优，据说能够从 UI 角度治理 单个 Project/NS 中万级的 workload，基本上齐全能笼罩咱们的应用极限了。期待咱们和 Rancher 再次单干，而后给大家奉上新的性能实际分享。
如果你也有治理大规模集群的应用场景或需要，能够通过中武官网（https://www.rancher.cn）分割 SUSE Rancher，来为你的集群保驾护航！
