转载：基于 KubeSphere 的 Kubernetes 生产环境部署架构设计及成本分析
前言
导图
1. 简介
1.1 架构概要说明
今天分享一个实际小规模生产环境部署架构设计的案例，该架构设计概要说明如下：
-
本架构设计适用于中小规模(<=50)的 Kubernetes 生产环境，大型环境没有经验，有待验证。
-
所有节点采用云上虚拟机的方式部署，出于某些原因所有组件均自建，没有使用云上产品（有条件建议使用云上产品）。
-
本架构设计不包含安全设备，不包含 Kubernetes 安全配置，安全要求高的环境不适用。
-
本架构设计属于第一版， 也是我在 Kubernetes 生产集群架构设计实践之路上走出的第一步，难免有一些不合理的地方（欢迎各位指正），后续会根据线上遇到的问题持续进行优化改进。
-
本架构设计是基于 KubeSphere 部署的 Kubernetes，后续的很多功能实现都依托于 KubeSphere。
-
本架构设计时使用的当时最新的软件版本，拿到目前来看也有一定的参考意义，完全可以直接套用，换一下软件版本即可（具体怎么换，请看下文）。
本文只介绍选型分析、部署架构图、部署架构设计说明、部署节点规划、上云总成本分析等内容，具体的安装部署暂不涉及。
1.2 选择 KubeSphere 的理由
KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。
KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。
-
完全开源，通过 CNCF 一致性认证的 Kubernetes 平台，100% 开源，由社区驱动与开发。
-
安装简单，使用简单，支持部署在任何基础设施环境，提供在线与离线安装，支持一键升级与扩容集群。
-
功能丰富，在一个平台统一纳管 DevOps、云原生可观测性、服务网格、应用生命周期、多租户、多集群、存储与网络。
-
模块化 & 可插拔，平台中的所有功能都是可插拔与松耦合，您可以根据业务场景可选安装所需功能组件。
-
具备构建一站式企业级的 DevOps 架构与可视化运维能力(省去自己用开源工具手工搭积木)。
-
提供从平台到应用维度的日志、监控、事件、审计、告警与通知，实现集中式与多租户隔离的可观测性。
-
简化应用的持续集成、测试、审核、发布、升级与弹性扩缩容。
-
为云原生应用提供基于微服务的灰度发布、流量管理、网络拓扑与追踪。
-
提供易用的界面命令终端与图形化操作面板，满足不同使用习惯的运维人员。
-
可轻松解耦，避免厂商绑定
除了上面的 10 条理由以外，更主要的是同类产品中 KubeSphere 属于最能打的，其它竞品在当年（2021 年）或多或少都有一些问题，无法走进我的心里。
其实一开始我是奔着 Rancher 去的，毕竟当年的 CloudStack 我也算是资深玩家。但是，Rancher 从上手到放弃我只用了一个下午，理由就不多说了，毕竟每个人的评判标准不一样，只是个人觉得不适合。
到了 2023 年的今天，虽然，KubeSphere 发展慢了下来、每次发布新版本或多或少都有一些问题、代码质量也不稳定（只用基本功能的话其实还好）。但是，在同类竞品中依旧是没有对手（如果有，请评论区留言告诉我）。
2. 部署架构设计
2.1 部署架构图
2.2 涉及软件版本
初次设计 v1.0 版时的主要软件版本
-
操作系统版本：centos7.9
-
kubesphere: v3.1.1
-
KubeKey版本：v1.1.1
-
Kubernetes版本：v1.20.4
-
docker版本：v19.03.15
-
GlusterFS：9.4
-
ElasticSearch：7.15
2023 年 8 月 适用的软件版本
-
操作系统版本： CentOS7.9
-
KubeSphere： v3.2.1（生产不建议用 3.3.x、3.4.x系列）
-
KubeKey： v3.0.10（老版本也行，只要支持 KubeSphere v3.2.x 和 Kubernetes v1.24.x 即可）
-
Kubernetes：v1.24.x
-
Containerd：1.6.4（替换掉 Docker）
-
GlusterFS：9.6（按理说应该用10.x，不知为何 CentOS 的源里居然没有）
-
ElasticSearch：8.x（选最新的就行）
2.3 网络规划
我们网络要求比较多。因此，根据不同功能模块，规划了不同的网段方便安全策略的控制。各位可根据需求合理规划，所有节点都放在一个网段也可以。
| 功能域 | 网段 | 说明 |
|---|---|---|
| 代理网关 | 192.168.8.0/24 | 代理网关作为南北向流量的转发节点，一定要和其他组件放在不同的网段 |
| k8s 集群 | 192.168.9.0/24 | k8s 集群内部节点使用 |
| 存储集群 | 192.168.10.0/24 | 持久化存储、日志存储域节点使用 |
| 中间件集群 | 192.168.11.0/24 | 独立在k8s集群外的，各种中间件节点使用 |
3. 部署架构设计说明
整体的部署架构设计采用了传统的分层、分域的思想（只是这思想被我乱用的分层有点多）概要为如下 10 层/域：
-
用户访问层（最终用户）
-
防火墙/WAF 等安全设备层（本文没有介绍，云上必备，内部可选）
-
代理网关层
-
负载均衡层
-
Kubernetes 集群域
-
持久化存储域
-
日志存储域
-
CI/CD 域
-
中间件域（在 K8S 集群之外，独立部署）
-
运维域
3.1 用户访问层
泛指最终用户（无论从哪个渠道入口访问平台实际业务的用户）
3.2 防火墙等安全设备层
安全是重中之重，所有上线的业务，安全设备是必不可少的，本架构设计里只提到了防火墙、WAF，实际使用中应该还有更多，这个只能大家根据需求自行组合了。
因为，安全设备层不在我的职责范围内，我只能说必须有，但是很多细节我也说不清，索性就不过多介绍了。
3.3 代理网关层规划
在代理网关的选择上，第一版选择了利用 Nginx 自建的方案，并没有选择 Ingress、Istio 等高级方案（刚接触并不熟悉没敢用）。
采用 2 台服务器部署典型的 Nginx + KeepAlived 服务，实现高可用的 7 层流量转发网关，根据域名判断规则将流量转入后端 K8S 集群节点对应的 NodePort。
该方案的优点就是对于新手比较友好，部署、维护、配置比较简单，因为都是比较熟悉的属于运维必备的玩法了。缺点就是配置文件的变更、同步都需要人工操作（最多加点自动化手段），有出错的风险。
3.4 负载均衡层规划
负载均衡属于 Kubernetes 集群内部使用，有三种可选方案。
-
采用公有云或是私有云平台上自带的弹性负载均衡服务（建议选择，很多云服务商内部的 SLB 是免费的）
需要配置监听器监听相应的服务端口
| 服务端口 | 协议 | 端口 |
|---|---|---|
| apiserver | TCP | 6443 |
| ks-console | TCP | 30880 |
| http | TCP | 80 |
| https | TCP | 443 |
-
采用 HAProxy 或是 Nginx 自建负载均衡（此次选择）
本架构设计由于某些原因，采用了 HAProxy 自建负载均衡的方案， 部署了 2 个HAProxy 节点，并使用 Keepalived 实现 VIP 故障切换保证了高可用。
这样的选择也增加了成本，毕竟 2 台 2C 4G 配置的机器一年的成本也有几千块，重点是还要自己部署维护。
所以，在公有云的场景下还是使用服务商提供的弹性负载均衡服务（SLB）比较好，内部使用的免费而且还不需要自己维护。
-
使用 KubeKey 自带的解决方案部署 HAProxy
从版本 v1.2.1 开始，KubeKey 提供了内置高可用模式，支持一键部署高可用集群环境。
KubeKey 的高可用模式实现方式称作本地负载均衡模式。具体表现为 KubeKey 会在每一个工作节点上部署一个负载均衡器（HAproxy），所有主节点的 Kubernetes 组件连接其本地的 kube-apiserver ，而所有工作节点的 Kubernetes 组件通过由 KubeKey 部署的负载均衡器反向代理到多个主节点的 kube-apiserver 。这种模式相较于专用到负载均衡器来说效率有所降低，因为会引入额外的健康检查机制，但是如果当前环境无法提供外部负载均衡器或者虚拟 IP（VIP）时这将是一种更实用、更有效、更方便的高可用部署模式。
目前，这种部署模式用的人也很多，他们给出的理由是部署简单。更多细节可以参考 使用 KubeKey 内置 HAproxy 创建高可用集群。
本架构方案初始设计时 KubeKey v1.1.1 并不支持该方式，个人建议生产环境不要用这种方案，而是采用独立部署的全局负载均衡器。
3.5 k8s 集群层规划
Kubernetes 集群初始部署采用 3 Master 和 N Worker 的架构，这样即实现了 Kubernetes 控制平面的高可用，也能满足前期业务部署对资源的需求，而且也有利于后期的升级扩容。
-
Master 节点：3 节点，部署 KubeSphere 和 Kubernetes 的管理组件、ETCD 等服务。
注意：本方案并没有把etcd单独部署，有条件或是规模较大的场景可以单独部署etcd
-
Worker 节点：前期选择 6 个节点，部署业务应用。各位可以根据实际需求决定初始化数量，但是，建议最少 3 个，后期扩容的时候增加节点的数量也是以 3 的倍数为单位。
Kubernetes 组件的高可用架构图如下：
这里，需要多说一句，不知道从何时开始互联网流行了一种 2 Master 的部署架构。从我做架构设计的经验来看，不建议各位使用 2M 的架构，毕竟既然考虑了高可用架构那么一定要顾及 ETCD ，2 节点的 ETCD 怎么玩高可用？
2M 的架构也只是解决了 Kube 组件的高可用，还是要找其他节点复用解决 ETCD 高可用的问题 。如果资源实在紧张可以选择 3 Master 复用为 Worker 的部署架构，也千万不要用 2M 的架构。
如果一定要用 2 M 的架构，那么只适用一个场景，那就是 ETCD 采取独立节点部署的方案。（如有不同意见，可以在评论区留言，欢迎真正的技术探讨）
3.6 持久化存储域规划
本架构设计选择了使用 GlusterFS 作为 Kubernetes 集群的持久化存储
-
3 个存储节点，安装部署 GlusterFS，其中一个节点安装 Heketi 作为管理端。
-
每个节点 1T 数据盘
存储组件架构图
存储选型说明：
-
持久化存储候选者
存储方案 优点 缺点 说明 Ceph 资源多 没有ceph集群故障处理能力，最好不要碰 曾经，经历过3副本全部损坏数据丢失的惨痛经历，因此没有能力处理各种故障之前不会再轻易选择 GlusterFS 部署、维护简单；多副本高可用 资料少 部署和维护简单，出了问题找回数据的可能性大一些 NFS 使用广泛 单点、网络抖动 据说生产环境用的很多，但是单点和网络抖动风险，隐患不小，暂不考虑 Longhorn 官宣企业级云原生容器存储解决方案，还未实践 -
第一季入选者
GlusterFS
-
说明
-
GlusterFS + Heketi 的存储解决方案，属于第一次做架构设计的尝试，属于摸着石头过河，也由于以前有过 GlusterFS 的运维经验，所以先用着，后期根据运行情况再重新调整。
-
大家请根据自己的存储需求和团队运维能力选择适合的方案，有技术实力的团队还是尽量选择 Ceph 吧。
-
因为我们的业务场景对于持久化存储的需求也就是存放一些 Log 日志，能承受一定的数据损失，也是选择 GlusterFS 的原因之一。
-
存储规划中假设 1T 数据满足需求，没考虑扩容，后续会做补充。
-
本次选型使用的是 Heketi 的对接方案，使用比较广泛，网上的参考用例比较多，但是该方案也存在一定弊端，各位需要根据自己的情况选择。
-
实现形式在底层创建了一堆的 LVM 卷，如果卷太多又太小的话，后期运维会比较麻烦，有一定的未知风险。
-
Heketi 项目官方已经停止更新了，项目处于维护状态，这就比较麻烦了，新入坑者慎入。（2023 年 7 月，该项目已经归档了）
3.7 日志存储域规划
日志存储选择了普遍使用的 ElasticSearch 作为日志存储方案，主要用于 KubeSphere 日志、事件等插件采集的日志数据的存储。
实际部署中采用了 3 个节点部署 ElasticSearch，利用 3 副本 实现数据的可靠性。KubeSphere 使用启用用户名和密码认证的 HTTP 协议去连接 ElasticSearch 存取数据。
由于不好预估日志规模，在磁盘空间规划上每个机器初期都分配了 1 T的数据盘。最后，我发现实际使用中30多个业务模块，日志按要求保留 180 天的场景下，500G 都用不了。
同时，初期在运维管理域部署了 Kibana 连接 ElasticSearch，实现可视化管理。后期，将 Kibana 移到了 K8S集群上，使用 Helm 的方式部署。
3.8 CI/CD 域规划
CI/CD 并没有使用太复杂的功能，主要使用了 KubeSphere 内嵌的 devops 插件，利用 Jenkins 流水线实现了应用自动构建、镜像上传、自动发布、审核发布等功能。
主要包含以下组件：
-
Jenkins，使用 KubeSphere 定制的 devops 插件（在 Kubernetes 集群上部署 Jenkins 及相应的构建任务容器）
-
GitLab，开发代码、运维代码管理，实现GitOps（在 K8S 集群外使用虚拟机独立部署）
-
Harbor，镜像仓库（在 K8S 集群外与 GitLab 在一台虚拟机上独立部署）
3.9 中间件域规划
有一些数据或是服务，在做架构设计时觉得部署在 K8S 集群上不靠谱，所以采用了在 K8S 集群外部的虚拟机上独立部署。
早期的规划是包含 MySQL、RabbitMQ、RocketMQ、Redis 等组件的，后来只独立部署了 MySQL，其他组件均安排到了 Kubernetes 之上。
-
独立部署主从复制模式的 MySQL 数据库，适合中小规模使用。大规模需要专业运维人员或是使用云上成熟的产品，有条件建议使用云服务商的RDS产品
多说一句，中间件的选型上如果是在公有云环境，最好对比一下云上产品，如果成本差不多，更建议选择云上的成熟产品。
3.10 运维管理域规划
监控、告警、自动化运维、其他运维辅助工具都规划在了运维管理域，机器的分配可以根据实际情况规划。
主要包含以下组件：
-
Ansible，自动化运维管理工具，执行日常批量运维管理操作。
-
Prometheus、Alertmanager， 用于实现 K8S 集群和集群上部署的业务应用组件的监控和告警（初期计划是自己搭建，后来发现 KubeSphere 集成的也挺好用，就暂时放弃了自建）。
-
Kibana，对接 ElasticSearch，实现数据可视化管理。
4. 部署节点规划
先看一眼总数，整个集群使用了 23 台虚拟机，120 核 CPU、464 GB 内存、920 GB 系统盘、12500 GB 数据。
接下来我们详细说一下每一层的节点如何规划部署。（规划中没有包含防火墙、WAF等网络设备）。
4.1 代理网关节点规划
| 节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
|---|---|---|---|---|---|---|---|
| nginx代理 | nginx-1 | 2 | 4 | 40 | 192.168.8.2/192.168.8.1 | 自建域名网关，暂时未采用 Ingress | |
| nginx代理 | nginx-2 | 2 | 4 | 40 | 192.168.8.3/192.168.8.1 | 自建域名网关，暂时未采用 Ingress | |
| 合计 | 2 | 4 | 8 | 80 |
4.2 Kubernetes 集群节点规划
| 节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
|---|---|---|---|---|---|---|---|
| 负载均衡 | k8s-slb-1 | 2 | 4 | 40 | 192.168.9.2/192.168.9.1 | ||
| 负载均衡 | k8s-slb-2 | 2 | 4 | 40 | 192.168.9.3/192.168.9.1 | ||
| Master | k8s-master-1 | 8 | 32 | 40 | 500 | 192.168.9.4 | |
| Master | k8s-master-2 | 8 | 32 | 40 | 500 | 192.168.9.5 | |
| Master | k8s-master-3 | 8 | 32 | 40 | 500 | 192.168.9.6 | |
| Worker | k8s-node-1 | 8 | 32 | 40 | 500 | 192.168.9.7 | |
| Worker | k8s-node-2 | 8 | 32 | 40 | 500 | 192.168.9.8 | |
| Worker | k8s-node-3 | 8 | 32 | 40 | 500 | 192.168.9.9 | |
| Worker | k8s-node-4 | 8 | 32 | 40 | 500 | 192.168.9.10 | |
| Worker | k8s-node-5 | 8 | 32 | 40 | 500 | 192.168.9.11 | |
| Worker | k8s-node-6 | 8 | 32 | 40 | 500 | 192.168.9.12 | |
| 合计 | 11 | 76 | 296 | 440 | 4500 |
重点说明： 由于初次上线怕资源不够，Master 节点的配置有点多，实际使用中 4C 16G 足够了（第二版的架构设计中已经改正了）。
4.3 存储节点规划
存储节点包含持久化存储和日志存储节点
| 节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
|---|---|---|---|---|---|---|---|
| 存储节点 | storage-1 | 4 | 16 | 40 | 1000 | 192.168.10.1 | |
| 存储节点 | storage-2 | 4 | 16 | 40 | 1000 | 192.168.10.2 | |
| 存储节点 | storage-3 | 4 | 16 | 40 | 1000 | 192.168.10.3 | |
| 日志存储节点 | elastic-1 | 4 | 16 | 40 | 1000 | 192.168.10.4 | |
| 日志存储节点 | elastic-2 | 4 | 16 | 40 | 1000 | 192.168.10.5 | |
| 日志存储节点 | elastic-3 | 4 | 16 | 40 | 1000 | 192.168.10.6 | |
| 合计 | 6 | 24 | 96 | 240 | 6000 |
4.4 中间件节点规划
| 节点角色 | 主机名 | CPU(核) | 内存(GB) | 系统盘(GB) | 数据盘(GB) | IP | 备注 |
|---|---|---|---|---|---|---|---|
| MySQL-主 | db-master | 4 | 16 | 40 | 500 | 192.168.11.2/192.168.11.1 | 数据盘可以选高IO的SSD |
| MySQL-从 | db-slave | 4 | 16 | 40 | 500 | 192.168.11.3/192.168.11.1 | 数据盘可以选高IO的SSD |
| 配置管理 | harbor | 4 | 16 | 40 | 500 | 192.168.11.10 | 安装 GitLab 和 Harbor （配置可缩） |
| Prometheus | monitor | 4 | 16 | 40 | 500 | 192.168.11.11 | 安装 Ansible，用于自动化运维 |
| 合计 | 4 | 16 | 64 | 160 | 2000 |
上面的节点资源配置规划，多少有几点不合理的地方，或者可以说是可以优化改进的地方，欢迎各位在评论区留言讨论。
5. 成本分析
回顾一下汇总的资源总数，整个集群使用了 23 台虚拟机，120 核 CPU、464 GB 内存、920 GB 系统盘（不要钱）、12500 GB 数据。
看着这些汇总数据，我自己都有点害怕，降本增效的当下，这有点多啊（实际上还是有优化空间的，差不多能减下去三分之一）。
接下来我们根据节点规划详细算算账，这到底要花多少银子？
货比三家，特意选了三家公有云服务商，用官方提供的价格计算器算了算公开报价（所有报价均为 2023 年 8 月报价）
有三点需要特别注意：
-
规划中没有包含防火墙、WAF等网络设备。
-
本报价只是公开报价成本，仅供参考。（渠道不同，各大云平台折扣也不同）
-
为了对比报价成本，所有选型都用的参数类似的产品，实际使用中请根据需求调整，例如，CPU、硬盘的调整。
5.1 计算节点类型汇总及成本分析
配置规格汇总
| 配置类型 | 数量 |
|---|---|
| 2C 4G | 4 |
| 4C 16G | 10 |
| 8C 32G | 9 |
| 合计 | 23 |
公开报价汇总
| 公有云平台 | 2C 4G（单价） | 2C 4G（4台总价 ） | 4C 16G（单价） | 4C 16G（10台总价） | 8C 32G（单价） | 8C 32G（9台总价） | 备注 |
|---|---|---|---|---|---|---|---|
| 阿里云 | 2,386.80 | 9,547.20 | 5,902.80 | 59,028.00 | 11,662.80 | 104,965.20 | 北京、通用型 g6（计算型）、系统盘（高效云盘） |
| 华为云 | 1,661.50 | 6,646.00 | 4,279.60 | 42,796.00 | 8,419.10 | 75,771.90 | 北京、通用计算 S6、系统盘（高IO） |
| 天翼云 | 1,734.00 | 6,936.00 | 4,610.40 | 46,104.00 | 9,057.60 | 81,518.40 | 北京、通用型、系统盘（高 IO） |
说明： 阿里云只有计算型里有 2C 4G 的配置。
5.2 数据盘类型汇总及成本分析
因为，系统盘不用额外算钱，包含在计算资源之内（实际上在云主机选择的时候可以选择硬盘大小，大小不同价格也不同）。所以，我们只给数据盘买单。磁盘类型设计方案中使用了统一的高IO类型，实际中请根据服务需要选择。
磁盘规格汇总
| 数据盘规格 | 数量 |
|---|---|
| 500G | 13 |
| 1000G | 6 |
| 合计 | 19 |
公开报价汇总
| 公有云平台 | 500G（单价） | 500G（13 块总价） | 1000G（单价） | 1000G（6 块总价） | 备注 |
|---|---|---|---|---|---|
| 阿里云 | 2,146.20 | 27,900.60 | 4,292.40 | 25,754.40 | 北京、高效云盘、0.245/时（500G） |
| 华为云 | 1,750.00 | 22,750.00 | 3,500.00 | 21,000.00 | 北京、高IO |
| 天翼云 | 2,040.00 | 26,520.00 | 4,080.00 | 24,480.00 | 北京、高IO |
5.3 总成本合计分析
| 云平台 | 计算资源总价（人民币/元/年） | 存储资源总价（人民币/元/年） | 最终总价 |
|---|---|---|---|
| 阿里云 | 173,540.40 | 53,655.00 | 227,195.40 |
| 华为云 | 125,213.90 | 43,750.00 | 168,963.90 |
| 天翼云 | 134,558.40 | 51,000.00 | 185,558.40 |
综合算下来，这套架构使用的云上资源成本多少还是有点费钱的，预计公开报价总成本最少需要人民币 168,963.90 元/年。作为一个合格的运维架构师，架构设计中成本考虑是一个重要因素，要是拿不到很好的折扣价，老板估计要干掉我了。（至于实际价格就各凭本事喽！！！）
5. 总结
本文分享了我设计的第一版基于 KubeSphere 部署 Kubernetes 集群的部署架构规划方案， 此方案是一个真实的小规模生产环境部署架构设计的案例，该生产环境基于 KubeSphere v3.1.1 和 Kubernetes v1.20.4 已经稳定运行了将近 2 年，运行期间只遇到过 3 个 重大问题。
-
到一年期的时候更换证书（运维不当，证书到期后才发现，手工用命令更换证书，重启相关服务后解决）
-
GlusterFS 存储扩容 1T 硬盘（直接添加新硬盘，使用 Hekiti 扩容即可）
-
ElasticSearch 无法写入数据（这个是因为索引最大值配置造成的，更该配置后解决）
除上述 3个 问题之外，在运维得当的前提下，并没有发现其他重大故障。
概括一下，本文主要从以下几个方面介绍了第一版的部署架构设计方案：
-
整个集群的部署架构图
-
所有涉及的主要软件的版本
-
网络规划设计
-
部署架构分层设计思想及 10 层规划的详细说明（本文核心价值）
-
部署节点规划及成本分析
这套部署架构设计方案是我设计的第一套 Kubernetes 生产环境部署方案，多少会有一些不合适的地方，比如 Master 节点资源分配过多、数据盘分配的过大、ElacticSearch 是否需要高可用等。（其它读者觉得不合理的地方，也欢迎评论区留言或是私信我讨论交流）。
所以，此架构方案运行的生产环境的持续运维中，我也根据出现的问题结合监控数据等可视化数据做了总结分析，设计了第二版的部署架构，也会在后期整理分享给大家，请持续关注哟！！！
标签：架构设计,存储,Kubernetes,部署,KubeSphere,集群,节点 From： https://blog.csdn.net/Richardlygo/article/details/140845244