写点什么

最佳实践丨使用 Rancher 轻松管理上万资源不是梦

  • 2021-07-13
  • 本文字数:2468 字

    阅读完需:约 8 分钟

最佳实践丨使用Rancher轻松管理上万资源不是梦

Rancher 作为一个开源的企业级 Kubernetes 集群管理平台。你可以导入现有集群,如 ACK、TKE、EKS、GKE,或者使用 RKE、RKE2、K3s 自定义部署集群。


作为业界领先的多集群管理平台,Rancher 可以同时纳管上千个集群和上万个节点。同时,大家也不必担心运维管理大规模集群和节点会增加额外的负担,社交通讯软件 LINE 5 个人就足以管理 130 个集群的 2000 个节点


如何在 Rancher 中管理大规模的集群和节点这次暂且不谈,之前已经介绍过很多次了。今天我们只聊如何在单个集群中管理大规模的项目、命名空间等资源。

如何在单个集群中管理大规模的项目和命名空间

  • 命名空间:命名空间是 Kubernetes 的一个概念,它允许在一个集群中建立一个虚拟集群,这对于将集群划分为单独的“虚拟集群”很有用,每个虚拟集群都有自己的访问控制和资源配额。


  • 项目:一个项目就是一组命名空间,它是 Rancher 引入的一个概念。项目允许您将多个命名空间作为一个组进行管理并在其中执行 Kubernetes 操作。您可以使用项目来支持多租户,例如设置团队可以访问集群中的某个项目,但不能访问同一集群中的其他项目。


从层次上来说,集群包含项目,项目包含命名空间。如果把公司理解成是一个集群,那么项目对应的就是部门或者团队,我们可以给某个部门或者团队针对不同的项目去划分权限来管理多个命名空间。


所以,我们在生产环境中会创建大量的项目和命名空间,那么如何规划这些项目和命名空间呢?


  1. 建议项目按照部门或者团队去划分,针对不同的项目授予相关访问控制

  2. 每个项目内具有不同目的的环境使用命名空间去隔离,例如:生产环境和测试的环境


为了验证在 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


内核参数

功能说明

net.ipv6.conf.all.disable_ipv6 = 1

禁用 IPv6

net.ipv6.conf.default.disable_ipv6 = 1

禁用 IPv6

fs.file-max=65535

最大可以打开的文件描述符数量,注意是整个系统。    

net.ipv4.tcp_max_syn_backlog = 65536

对于还未获得对方确认的连接请求,可保存在队列中的最大数目。如果服务器经常出现过载,可以尝试增加这个数字。

net.ipv4.tcp_tw_reuse = 1

表示是否允许将处于 TIME-WAIT 状态的 socket(TIME-WAIT 的端口)用于新的 TCP 连接 

net.ipv4.tcp_tw_recycle = 1

能够更快地回收 TIME-WAIT 套接字。

net.ipv4.tcp_max_tw_buckets = 60000

所允许存在 time_wait 状态的最大数值,超过则立刻被清除并且警告。

net.core.somaxconn = 32768

定义了系统中每一个端口最大的监听队列的长度,这是个全局的参数。

net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096

内核的 Arp 多级缓存表容量,一般单机 Pod 数较多时,需要调整该参数。

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216

TCP 缓冲区优化


Kube-apiserver


针对原生资源和 CRD 的 API 的并发能力与缓存优化,提升 API List-Watch 的性能:

内核参数

功能说明

--max-requests-inflight

默认值 400;用于 read 请求的访问频率限制;建议 1600 或更高;

--max-mutating-requests-inflight

默认值 200;用于 write 请求的访问频率限制;建议 800 或更高;

--event-ttl max-requests-inflight

默认值 1h0m0s;用于控制保留 events 的时长;集群 events 较多时建议 30

--default-watch-cache-size

默认值 100;用于 List-Watch 的缓存池;建议 1000 或更多

--delete-collection-workers

默认值 1;用于提升 namesapce 清理速度,有利于多租户场景;建议 10;

--kubelet-timeout

默认值为 5s;kubelet 超时时间


本文的重点不是调优,所以只介绍一些常用的参数,更详细的参数(例如:kube-controller-manager、kube-scheduler、kubelet、kube-proxy)说明还请大家参考 Kubernetes 官网。

后记

从以上验证结果来看,Rancher 具有在单个集群中管理大规模项目和命名空间的能力,只要合理的使用正确的方式搭建集群和部署业务,就不会对 Rancher 带来太大的压力,也不存在性能问题,同时也要根据集群规模来调优主机和 Kubernetes 参数,使其发挥出最佳性能。


作者介绍:

王海龙,SUSE Rancher 社区技术经理,负责 Rancher 中国技术社区的维护和运营。拥有 6 年的云计算领域经验,经历了 OpenStack 到 Kubernetes 的技术变革,无论底层操作系统 Linux,还是虚拟化 KVM 或是 Docker 容器技术都有丰富的运维和实践经验。


本文转载自:RancherLabs(ID:RancherLabs)

原文链接:最佳实践丨使用Rancher轻松管理上万资源不是梦

2021-07-13 08:002907

评论

发布
暂无评论
发现更多内容

一文你带快速认识Vue-Router路由

华为云开发者联盟

html Vue vue-router 路由 路由管理器

都啥年代了,求你别再说Redis是单线程了!

Java redis 编程 程序员

「免费开源」基于Vue和Quasar的前端SPA项目crudapi后台管理系统实战之EXCEL数据导入(九)

crudapi

Vue crud crudapi qusar 数据导入

奇亚矿机系统,Bzz分币系统,云算力APP开发

CloudQuery 的数据安全技术运用

BinTools图尔兹

Java 数据库 sql 数据安全

网络攻防学习笔记 Day40

穿过生命散发芬芳

网络攻防 6月日更

2021年马士兵老师1000道Java大厂面试真题视频解析+笔记+源码

Java架构追梦

Java 架构 面试 马士兵

5分钟带你玩转国内首款研发自动化工具PingCode Flow

PingCode研发中心

研发管理 研发效能 自动化管理 研发工具

淘宝“618”双11系统架构是如何设计的呢?这份Java千亿级并发系统架构设计笔记告诉你答案

Java 程序员 架构 计算机

【LeetCode】零钱兑换 IIJava题解

Albert

算法 LeetCode 6月日更

并发王者课-青铜9:防患未然-如何处理线程中的异常

MetaThoughts

Java 多线程 并发

【布道API】API端点/资源命名最佳实践

devpoint

RESTful Rest API 6月日更

百度大规模Service Mesh落地实践

百度Geek说

Service Mesh 软件架构

我的编辑器能玩贪吃蛇,一起玩不?

华为云开发者联盟

大前端 编辑器 贪吃蛇 Blot Quill

汽车之家:基于 Flink + Iceberg 的湖仓一体架构实践

Apache Flink

flink

基于 Flink 打造的伴鱼实时计算平台 Palink 的设计与实现

Apache Flink

flink

工厂管理没有头绪?那是你还没有可视化操控设备

一只数据鲸鱼

数据可视化 工业互联网 工业4.0 智慧工厂

PHP ppa 不再支持过时的 Ubuntu 16.04,请立即升级 20.04

大龄程序员老羊

php ubuntu 架构 DevOps

6月18日华为云携手中科院上海药物所,深度解读AI药物研发技术

华为云开发者联盟

AI 华为云 药物 TechWave EIHealth

并发王者课-青铜10:千锤百炼-如何解决生产者与消费者经典问题

MetaThoughts

Java 多线程 并发

液体测量技术:从水到血液

不脱发的程序猿

物联网 液体测量技术 测量技术 ADI

Hi,HarmonyOS!融云全系产品已成功适配鸿蒙 OS 2.0

融云 RongCloud

WebRTC 用例和性能

anyRTC开发者

音视频 WebRTC RTC sdk

竞赛|数据竞赛Top解决方案开源整理

不脱发的程序猿

开源 数据竞赛

JAVA中的浮点数与二进制

加百利

Java 后端 二进制 6月日更

Scrum为何倡导固定迭代周期?

万事ONES

项目管理 Scrum 敏捷开发 Agile ONES

浪潮云说丨数据工场助力行业数据发挥生产要素新价值

云计算

一文回顾 Java 入门知识(下)

逆锋起笔

Java 面向对象 JAVA开发 java基础 javase

对话吴军:人工智能如何推动金融行业的数字化转型

索信达控股

人工智能 大数据 金融科技 数字化转型 金融

最佳实践丨使用Rancher轻松管理上万资源不是梦_架构_Rancher_InfoQ精选文章