源起
知乎是中文互联网高质量的问答社区,每天有上千万用户在知乎分享知识、经验和见解,找到自己的答案。为配合不同阶段的业务发展需求,知乎容器平台也在不断演进、提升,目前几乎所有的业务都运行在容器上。
这两年知乎开始使用 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 管理中小规模集群时,Rancher UI 提供的功能几乎可以满足我们所有的需求,并且 UI 也非常流畅。
但随着业务量的增加,集群规模不断的扩大,当我们扩大到使用一个 Rancher 管理近十个集群、近万节点和几十万 pod 时(单集群最大规模将近几千个节点和数十几万 pod),操作 Rancher UI 频繁会出现卡顿并且加载时间过长的问题,个别页面需要 20 多秒的时间才能完成加载。严重时可能会造成连接不到下游集群的情况,UI 提示“当前集群 Unavailable ,在 API 准备就绪前,直接与 API 交互功能不可用。”
没错,我们碰到了 Rancher 的性能问题。尤其是超级管理员用户,登录时需要加载的数据量较大,基本上UI处于一种不可用的状态,下游集群也断连频繁。
破晓
从上面的现象来看,使用 Rancher 管理超大规模集群似乎遇到了性能问题,影响了使用体验。随后寻求 Rancher 本土技术团队帮忙,经过几次高效的线上会议沟通,基本找到根本原因:
经了解,如果要通过社区版解决该问题,操作会相当复杂。但企业版 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/kops/blob/master/nodeup/pkg/model/sysctls.go)
开启资源缓存
开启资源缓存后,一些涉及读取 Local 集群数据的接口,将会走 Cache 模式,极大提升 API list-all 的性能,针对我们环境中节点数特别多的场景有明显效果。
目前增加了缓存的资源如下:
企业版中针对连接下游集群的方式进行了优化,并且支持多种连接下游集群的方式,企业版用户常用的连接策略包括:集群连接模式
默认策略,就是不修改连接方式,沿用社区版连接下游集群的策略。
企业版中默认 Tunnel 中的 k8s rest client 的 timeout 值为 60s,可以有效减少 heavy load 时下游集群数据查询的失败几率,性能提升有限,但是请求成功率会有很大提升。
默认情况下,通过 Tunnel 使用下游集群的 Kubernetes API Service(如10.43.0.1)进行通信。如果自建集群的外部,有一个性能更好的 Kubernetes API LB,可以将连接下游集群的 apiEndpoint 改为 LB 入口地址,这样可以通过 Kubernetes API LB 分担压力,提升连接下游集群的速度。
启用直连和 Tunnel 双链路模式之前,需要确保下游集群有一个从 Rancher Server 网络直接可达的 apiEndpoint(参考策略二)。优化后,Rancher API 中针对下游集群请求的 v3 接口走直连,其余还是走 Tunnel,这样可以有效分散流量,避免大量数据都在 Tunnel 中传输。相对策略二,性能进一步得到提升,但是比较依赖基础网络规划。
最终,我们选择了 “策略二” 去连接下游集群,因为我们有一个性能强大的Kubernetes API LB。当切换连接下游集群的链路会出现短暂的下游集群不可达的情况,但不会影响下游集群的业务运行。
硕果
首先,Rancher 企业版 UI 对于我们团队来说十分方便,左侧导航栏可以轻松找到各种功能,适合国人的使用习惯。可能是我们从事基础设施管理的缘故,对这种极简 UI 风格可以说是非常喜欢。
其次,通过上述策略优化后,提升了 Dial Kubernetes API 时的 Timeout,最终几乎看不到因超时导致的请求失败。另外,使用下游集群的 Kube api-server 的 LB Endpoint 作为请求目标,下游集群断联现象已经消失,堪称从村道换成了高速公路。此外,支持部分接口通过缓存快速检索,尤其对于 Node 资源,从 20+ 秒的响应时间缩短至不到 5 秒。其他比较重要的接口也进行了比对,平均速度提升了大概 75% 以上。
在 Rancher 企业版中,用户可以通过优化下游集群的参数、设置连接下游集群的策略、开启缓存等方式来大幅度优化集群性能,进而轻松管理大规模集群。从上述实践可以看到,只要合理的做好调优和规划,即便是像知乎这样超大规模的集群,也能和小规模集群有一样的使用体验。
本文撰写时,Rancher 本土团队正在对企业版性能做二次调优,据说可以从 UI 角度管理单个 Project/NS 中万级的 workload,基本上完全能覆盖我们的使用极限了。期待我们和 Rancher 再次合作,然后给大家奉上新的性能实践分享。
好文章,需要你的鼓励
南洋理工大学研究团队开发了WorldMem框架,首次让AI拥有真正的长期记忆能力,解决了虚拟世界模拟中的一致性问题。该系统通过记忆银行存储历史场景,并使用智能检索机制,让AI能准确重现之前的场景和事件,即使间隔很长时间。实验显示在Minecraft和真实场景中都表现出色,为游戏、自动驾驶、机器人等领域带来广阔应用前景。
AWS通过升级SageMaker机器学习平台来扩展市场地位,新增观测能力、连接式编码环境和GPU集群性能管理功能。面对谷歌和微软的激烈竞争,AWS专注于为企业提供AI基础设施支撑。SageMaker新功能包括深入洞察模型性能下降原因、为开发者提供更多计算资源控制权,以及支持本地IDE连接部署。这些更新主要源于客户需求,旨在解决AI模型开发中的实际问题。
MTS AI研究团队提出RewardRanker系统,通过重排序模型和迭代自训练显著提升AI代码生成质量。该方法让13.4B参数模型超越33B大模型,在多种编程语言上表现优异,甚至在C++上超越GPT-4。通过引入困难负样本和PPO优化,系统能从多个代码候选中选出最优方案,为AI编程助手的实用化奠定基础。