本文作者:运维有术。
今天分享的主题是:如何规划设计一个高可用、可扩展的中小规模生产级 K8s 集群?
通过本文的指导,您将掌握以下设计生产级 K8s 集群的必备技能:
集群规划能力
组件选型能力
运维规划能力
成本优化能力
本文架构设计概要说明如下:
本文主要内容包括以下几个部分:
整个架构完整的安装部署步骤将在后续系列文档中详细介绍。
KubeSphere v4 引入了全新的 LuBan 可插拔架构,这是自 2018 年以来最具革命性的一次升级。以下是选择 KubeSphere v4 的核心理由:
1、全新的 LuBan 微内核架构
2、解决了历史版本的核心痛点
3、更强大的扩展能力
4、企业级云原生基础能力
5、面向未来的云原生操作系统
6、可轻松解耦,避免厂商绑定
除了上述理由外,KubeSphere 在同类产品中的竞争力依然保持领先。截至 2025 年,无论是功能完整性、易用性还是社区活跃度,在开源容器平台领域都处于领先地位。它不仅继承了早期版本的优势,还通过持续创新保持了技术领先性。如果您知道有其他更好的替代方案,欢迎在评论区留言讨论。
2025 年 1 月 适用的软件版本:
网络规划方案一:
分层、多网段,适用场景:
功能域 | 网段 | 说明 |
---|---|---|
网络资源域 | 192.168.8.0/24 | 堡垒机、WAF、代理网关作为南北向流量的转发节点,一定要和其他组件放在不同的网段 |
K8s 集群 | 192.168.9.0/24 | K8s 集群内部节点使用 |
存储平面 | 192.168.10.0/24 | 持久化存储、对象存储、日志存储域节点使用 |
运维/CICD域 | 192.168.11.0/24 | 运维监控工具、中间件、CI/CD工具 |
网络规划方案二:
分层、同网段,适用场景:
功能域 | 网段 | 说明 |
---|---|---|
网络资源域/K8s 集群/存储集群/运维/CICD域 | 192.168.9.0/24 | 所有服务部署在相同的网段 |
整体的部署架构设计采用分层分域的思想,主要分为以下7个层/域:
最终用户访问入口,支持多种访问渠道。
防火墙、WAF等安全防护、确保整体架构安全性。
实现流量转发和负载均衡,包括自建网关、负载均衡、K8S网络服务。
容器编排与管理、应用部署与运行。
提供数据持久化能力包括:与 K8s 集群集成的持久化存储、对象存储、日志存储。
提供整体的 DevOps能力,包括代码存储、镜像存储、持续集成、持续部署、自动化流水线等。
提供自动化运维和可观测性管理等综合能力,包括自动化运维工具、监控告警、运维大屏等。
此外,可根据实际需求在 K8s 集群外增设中间件域,用于部署常用中间件和其他服务,比如对性能要求较高的数据库。
用户访问层主要面向最终用户,包括但不限于:
无论通过何种渠道访问平台的实际业务功能,都需要经过用户访问层的统一入口,以确保访问的规范性和安全性。
安全是重中之重,所有上线的业务,安全设备是必不可少的,本架构设计里只提到了防火墙、WAF、堡垒机,实际使用中应该还有更多,这个只能大家根据需求自行组合了。因为,安全设备层不在我的职责范围内,我只能说必须有,但是很多细节我也说不清,索性就不过多介绍了。
1、防火墙(FireWall)
2、Web应用防火墙(WAF)
3、堡垒机
除以上组件外,企业可根据自身安全需求,增加 IDS/IPS、漏洞扫描等其他安全设备。安全体系的具体实现需要专业安全团队的规划和建设。
代理转发层提供了三种主流的技术方案选择,可以根据实际需求进行单独使用或组合部署。
1、自建 Nginx 代理网关
采用双机热备的架构,部署 Nginx + Keepalived 服务实现负载均衡的、高可用的四层和七层流量转发,通过配置域名规则或是 IP + 端口,将请求转发至后端 K8s 集群对应的 NodePort 端口。
优点:
缺点:
2、K8s Ingress
K8s 原生的 Ingress 控制器方案,本设计采用两个主流实现:
3、K8s + 负载均衡方案
结合外部负载均衡实现服务暴露和流量转发。云环境可使用云厂商提供的负载均衡服务。自建环境,可选用开源方案,主要包括:
K8s 集群采用高可用的 3 Control + N Worker + N GPU Worker架构设计,该架构具有以下特点:
Control 节点配置:
通用 Worker 节点配置:
GPU Worker 节点配置:
集群高可用,采用 KubeKey 内置的本地负载均衡模式:
高可用模式说明:
存储平面有三种类型:持久化存储、日志存储、对象存储。
1、持久化存储
本架构设计选择了使用 OpenEBS 和 Ceph 组合的方式,作为 K8s 集群的持久化存储
OpenEBS :使用 Worker 节点本地存储,提供 local 模式的本地存储解决方案,可以获取更高的性能。适用自身有高可用数据同步、存储方案的应用,例如 MySQL 主从复制,ETCD 集群。
Ceph:提供跨节点、分布式、多副本、高可用的存储解决方案,
持久化存储方案选型说明:
存储方案 | 优点 | 缺点 | 说明 |
---|---|---|---|
Ceph | 分布式存储、高可用性、高扩展性、支持多副本 | 运维复杂、故障处理难度大、需要专业技能 | 曾经经历过 3 副本全部损坏数据丢失的惨痛经历,因此没有能力处理各种故障之前不会再轻易选择 |
OpenEBS | 易于部署和管理、支持本地存储和网络存储、动态供应、支持快照和备份 | 相比Ceph性能略低、功能相对简单 | 适合中小规模部署,特别是对运维要求不高的场景 |
NFS | 使用广泛、部署简单、成熟稳定 | 单点故障风险、网络抖动影响大、性能受限 | 生产环境使用较多,但单点和网络抖动风险较大,需要谨慎评估 |
Longhorn | 企业级存储方案、支持备份恢复、支持数据复制、界面友好 | 社区相对较新、生产验证案例较少 | Rancher 开源的企业级云原生容器存储解决方案,值得关注但需要更多实践验证 |
存储方案的选择需要综合考虑以下因素:
业务对数据可靠性的要求
团队的技术储备和运维能力
成本预算
性能需求
对于具备高可用能力的工作负载,建议选择 OpenEBS 作为存储方案,可以充分利用本地存储的性能优势
在我们的业务场景中,主要用于存储日志数据,可以容忍短期的数据不可用和数据丢失。基于这一特点,我们选择了 Ceph 作为存储方案
初期存储容量规划为每个节点 1TB,可根据实际使用情况动态扩容。建议预留 20%-30% 的缓冲空间用于应对数据增长
2、日志存储
日志存储选择了两种方案:
方案一:广泛使用的 EL(F)K 方案,主要用于存储和分析 KubeSphere 日志、事件等插件采集的日志数据
ElasticSearch 具有以下优势:
实际部署采用了 3 节点的 ElasticSearch 集群架构:
存储容量规划:
同时部署了 Kibana 作为日志分析和管理平台:
方案二:轻量的方案 PLG
3、对象存储
对象存储选择了 MinIO 作为解决方案,主要用于 Kubernetes 集群中需要对象存储服务的应用场景。MinIO 具有以下特点:
CI/CD 采用了轻量级的配置方案,主要基于 KubeSphere 内置的 DevOps 功能进行构建。通过 Jenkins 流水线实现了完整的 CI/CD 自动化流程,包括代码构建、镜像制作与推送、应用部署、发布审核等环节。
主要组件架构如下:
1、Jenkins
2、GitLab
在 K8s 集群之外独立部署
统一管理应用代码和运维配置
支持 GitOps 工作流,提供代码版本控制和 CI 触发
3、Harbor
在 K8s 集群之外独立部署
与 GitLab 共用一台虚拟机
4、Nexus
监控、告警、自动化运维、其他运维辅助工具都规划在了运维管理域,机器的分配可以根据实际情况规划。
主要包含以下组件:
Ansible:
Prometheus、Alertmanager:
夜莺监控
有一些数据或是服务,在做架构设计时觉得部署在 K8s 集群上不靠谱,可以在 K8S 集群外部的虚拟机上独立部署。这样做的主要考虑是:
按最小节点规划,先看一眼总体的资源需求,整个集群使用了 20 台虚拟机,100核 CPU、376GB 内存、800GB 系统盘、16000GB 数据盘。
接下来我们详细说一下每一层的节点如何规划部署。
使用两台独立的虚拟机部署开源应用,自建 WAF 和 堡垒机,云上环境建议使用云服务商的产品。
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
WAF | waf | 4 | 8 | 40 | 192.168.9.51 | 部署开源 WAF,配置暂定后期根据运行情况调整。 | |
堡垒机 | jumperserver | 4 | 8 | 40 | 192.168.9.52 | 部署 JumpServer,配置暂定后期根据运行情况调整。 | |
合计 | 2 | 8 | 16 | 80 |
使用两台独立的虚拟机部署 Nginx + Keepalived,自建高可用的代理网关。
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
nginx代理 | nginx-1 | 2 | 4 | 40 | 192.168.9.61/192.168.9.60 | 自建代理网关 | |
nginx代理 | nginx-2 | 2 | 4 | 40 | 192.168.9.62/192.168.9.60 | 自建代理网关 | |
合计 | 2 | 4 | 8 | 80 |
规划说明:
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
Control 节点 | ksp-control-1 | 4 | 16 | 40 | 500 | 192.168.9.91 | 控制节点 |
Control 节点 | ksp-control-2 | 4 | 16 | 40 | 500 | 192.168.9.92 | 控制节点 |
Control 节点 | ksp-control-3 | 4 | 16 | 40 | 500 | 192.168.9.93 | 控制节点 |
Worker 节点 | ksp-worker-1 | 8 | 32 | 40 | 500 | 192.168.9.94 | 部署通用工作负载 |
Worker 节点 | ksp-worker-2 | 8 | 32 | 40 | 500 | 192.168.9.95 | 部署通用工作负载 |
Worker 节点 | ksp-worker-3 | 8 | 32 | 40 | 500 | 192.168.9.96 | 部署通用工作负载 |
GPU Worker 节点 | ksp-gpu-worker-1 | 8 | 32 | 40 | 500 | 192.168.9.97 | 部署AI、GPU应用型工作负载 |
GPU Worker 节点 | ksp-gpu-worker-2 | 8 | 32 | 40 | 500 | 192.168.9.98 | 部署AI、GPU应用型工作负载 |
GPU Worker 节点 | ksp-gpu-worker-3 | 8 | 32 | 40 | 500 | 192.168.9.99 | 部署AI、GPU应用型工作负载 |
合计 | 9 | 60 | 240 | 360 | 4500 |
存储节点包含持久化存储、日志存储、对象存储节点:
方案一:适合生产环境 ,每个存储角色按建议副本数配置节点数量和磁盘容量。
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
持久化存储 | ksp-storage-1 | 4 | 16 | 40 | 1000 | 192.168.9.101 | 部署 Ceph,三副本 |
持久化存储 | ksp-storage-2 | 4 | 16 | 40 | 1000 | 192.168.9.102 | 部署 Ceph,三副本 |
持久化存储 | ksp-storage-3 | 4 | 16 | 40 | 1000 | 192.168.9.103 | 部署 Ceph,三副本 |
日志存储节点 | elastic-1 | 4 | 16 | 40 | 1000 | 192.168.9.111 | 部署 ElasticSearch,三副本 |
日志存储节点 | elastic-2 | 4 | 16 | 40 | 1000 | 192.168.9.112 | 部署 ElasticSearch,三副本 |
日志存储节点 | elastic-3 | 4 | 16 | 40 | 1000 | 192.168.9.113 | 部署 ElasticSearch,三副本 |
对象存储节点 | minio-1 | 4 | 16 | 40 | 1000 | 192.168.9.121 | Minio 集群最小四个节点 |
对象存储节点 | minio-2 | 4 | 16 | 40 | 1000 | 192.168.9.122 | Minio 集群最小四个节点 |
对象存储节点 | minio-3 | 4 | 16 | 40 | 1000 | 192.168.9.123 | Minio 集群最小四个节点 |
对象存储节点 | minio-4 | 4 | 16 | 40 | 1000 | 192.168.9.124 | Minio 集群最小四个节点 |
合计 | 10 | 40 | 160 | 400 | 10000 |
方案二:适合研发测试环境,适配 Minio 集群最小 4 节点要求
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
存储节点 | minio-1 | 4 | 16 | 40 | 1000+1000+1000 | 192.168.9.101 | 部署Ceph、ElasticSearch、Minio |
存储节点 | minio-2 | 4 | 16 | 40 | 1000+1000+1000 | 192.168.9.102 | 部署Ceph、ElasticSearch、Minio |
存储节点 | minio-3 | 4 | 16 | 40 | 1000+1000+1000 | 192.168.9.103 | 部署Ceph、ElasticSearch、Minio |
存储节点 | minio-3 | 4 | 16 | 40 | 1000 | 192.168.9.104 | 部署 Minio |
合计 | 4 | 16 | 64 | 160 | 10000 |
不考虑高可用的问题,采用一个节点部署自动化运维工具 Ansible 以及 Prometheus、Grafana、夜莺等监控产品。
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
运维管理 | monitor | 4 | 16 | 40 | 500 | 192.168.9.71 |
不考虑高可用的问题,采用二个节点部署 GitLab、Harbor、Nexus、Jenkins 等组件。
节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
---|---|---|---|---|---|---|---|
CI | cicd-1 | 4 | 16 | 40 | 500 | 192.168.9.72 | |
CD | cicd-2 | 4 | 16 | 40 | 500 | 192.168.9.73 | |
合计 | 2 | 8 | 32 | 80 | 1000 |
上面的节点资源配置规划,不合理的地方,或是可以优化改进的地方,欢迎各位在评论区留言讨论。
回顾一下整个架构规划的计算和存储资源总数,整个最小集群使用了 20 台虚拟机,100核 CPU、376GB 内存、800GB 系统盘(不要钱)、16000GB 数据盘。
看着这些汇总数据,我自己都有点害怕,降本增效的当下,这有点多啊。
接下来我们根据节点规划详细算算账,这到底要花多少银子?
货比三家,特意选了几家公有云服务商,用官方提供的价格计算器算了算公开报价(所有报价均为 2025 年1 月报价)。
成本计算中有几点需要特别注意:
配置规格汇总:
配置类型 | 数量 |
---|---|
2C 4G | 2 |
4C 8G | 2 |
4C 16G | 10 |
8C 32G | 6 - 3台GPU = 3 |
合计 | 20 - 3=17 |
公开报价汇总:
公有云平台 | 2C 4G(单价) | 2C 4G(2台 总价) | 4C 8G(单价) | 4C 8G(2台 总价) | 4C 16G(单价) | 4C 16G(10台 总价) | 8C 32G(单价) | 8C 32G(3台 总价) | 备注 |
---|---|---|---|---|---|---|---|---|---|
青云 | 1,795.20 | 3,590.40 | 3,350.40 | 6,700.8 | 4,179.84 | 41,798.4 | 8,119.68 | 24,359.04 | 北京、企业型 e3/通用型 g7、系统盘(PL0,单盘IOPS性能上限1万) |
阿里云 | 1,730.43 | 3,460.86 | 3,256.85 | 6,513.7 | 4,122.10 | 41,221 | 8,040.19 | 24,120.57 | 北京、计算型 c7/通用型 g7、系统盘(PL0,单盘IOPS性能上限1万) |
华为云 | 1,878.20 | 3,756.4 | 3,476.40 | 6,952.8 | 4,807.60 | 48,076 | 9,335.20 | 28,005.6 | 北京、通用计算 S7、系统盘(通用型SSD) |
天翼云 | 1,734.00 | 3,468 | 3,304.80 | 6,609.6 | 4,610.40 | 46,104 | 9,057.60 | 27,172.8 | 北京、通用型s6、系统盘(高 IO) |
因为,系统盘不用额外算钱,包含在计算资源之内(实际上在云主机选择的时候可以选择硬盘大小,大小不同价格也不同)。所以,我们只给数据盘买单。磁盘类型设计方案中使用了统一的高IO类型,实际中请根据服务需要选择。
磁盘规格汇总:
数据盘规格 | 数量 |
---|---|
500G | 12-3 |
1000G | 10 |
合计 | 22-3 |
公开报价汇总
公有云平台 | 500G(单价) | 500G(9 块总价) | 1000G(单价) | 1000G(10 块总价) | 备注 |
---|---|---|---|---|---|
青云 | 5,712 | 51,408 | 11,424 | 114,240 | 北京、通用型SSD 5万IOPS/350MB吞吐量、¥13.6元/10 GB/月 |
阿里云 | 6,000 | 54,000 | 12,000 | 120,000 | 北京、ESSD PL1云盘、5万IOPS / 350MB吞吐量、¥1/1 GB/月 |
华为云 | 3,500 | 31,500 | 7,000 | 70,000 | 北京、通用型SSD、2万IOPS / 250MiB/s吞吐量、7 元/GB/年 |
天翼云 | 3,570 | 32,130 | 7,140 | 71,400 | 北京、通用型SSD、2万IOPS / 250MiB/s吞吐量、71.40 元/10GB/年、0.7 元/GB/月 |
云平台 | 计算资源总价(人民币/元/年) | 存储资源总价(人民币/元/年) | 最终总价 |
---|---|---|---|
青云 | 76,448.64 | 165,648 | 242,096.64 |
阿里云 | 75,316.13 | 174,000 | 249,316.13 |
华为云 | 86,790.8 | 101,500 | 188,290.8 |
天翼云 | 83,354.4 | 103,530 | 186,884.4 |
综合算下来,这套架构使用的云上资源成本多少还是有点费钱的,且各服务商因促销活动与优惠政策差异,导致价格浮动较大。作为一个合格的运维架构师,架构设计中成本考虑是一个重要因素,要是拿不到很好的折扣价,老板估计要干掉我了。(至于实际价格就各凭本事喽!!!)
免责声明:
笔者水平有限,尽管经过多次验证和检查,尽力确保内容的准确性,但仍可能存在疏漏之处。敬请业界专家大佬不吝指教。
本文所述内容仅通过实战环境验证测试,读者可学习、借鉴,但严禁直接用于生产环境。由此引发的任何问题,作者概不负责!