3、集群规划第一步：业务需求分析
业务需求分析是K8s集群规划的起点，决定了集群的规模、架构、资源配比与运维策略。如果跳过这一步直接选型或搭建，后续极易出现资源争抢、调度失衡、容量不足或过度浪费等问题。
3.1 业务需求收集清单
需求收集需要覆盖业务、运维、开发三个视角，形成可量化的输入。以下为标准化收集清单：
| 维度 | 关键问题 | 输出指标 |
|---|---|---|
| 业务规模 | 当前总实例数？未来6/12/24个月增长预期？ | Pod总数、命名空间数、服务数 |
| 资源画像 | 每个微服务的CPU/内存/GPU需求？峰值与均值？ | Request/Limit、资源利用率基线 |
| 流量特征 | 日活用户数？QPS峰值？是否存在突发流量？ | QPS、TPS、并发连接数、带宽 |
| 数据持久化 | 是否有状态服务？存储类型（块/文件/对象）？ | PV数量、存储容量、IOPS |
| 调度约束 | 是否需要GPU/FPGA？节点亲和性？拓扑分布？ | 节点标签、污点容忍、资源预留 |
| 可用性要求 | SLA目标？是否跨AZ/Region部署？ | 副本数、PodAntiAffinity、PDB |
实践建议：使用
kubectl top pod和Prometheus历史数据对现有业务做一周的资源基线采集，避免仅凭开发人员“估算”导致规划偏差。
3.2 应用类型分类
K8s集群规划必须按应用类型差异化设计。不同类型对调度、存储、网络、扩缩容的要求截然不同。
| 类型 | 典型代表 | 核心特征 | 规划要点 |
|---|---|---|---|
| 无状态应用 | Web Server、API Gateway、微服务 | Pod可任意迁移、不依赖本地存储 | HPA、PDB、Deployment滚动更新、Node弹性伸缩 |
| 有状态应用 | MySQL、Redis、Kafka、Elasticsearch | 依赖持久卷、Pod标识稳定、启动顺序敏感 | StatefulSet、PVC模板、Headless Service、拓扑约束 |
| 批处理/任务型 | Spark Job、数据ETL、模型训练 | 执行完成后退出、对启动延迟不敏感 | Job/CronJob、资源配额、GPU调度、Volcano/Kueue |
常见误区：将有状态应用直接使用Deployment部署，导致Pod重建后PVC绑定失败或数据丢失。必须使用StatefulSet并配合VolumeClaimTemplate。
3.3 流量模型预估
流量模型直接影响集群的节点规格、网络带宽、HPA阈值和Ingress容量设计。以下为三种典型流量模型：
- 平稳型：流量波动在±20%以内，如内部管理系统、后台服务。适合静态资源分配+保守HPA。
- 潮汐型：流量按天/周规律波动，如电商白天高、夜间低。适合Cluster Autoscaler + 按需节点池。
- 突发型：流量在秒级内暴涨数倍，如秒杀、热点事件。需要预留Buffer节点、PDB快速扩容、限流降级。
流量预估公式（以QPS为例）：
集群总QPS = 单Pod QPS × 副本数 × 冗余系数(1.5~2.0)
所需节点数 = ceil(总QPS / 单节点承载QPS)
单节点承载QPS = min(CPU瓶颈QPS, 内存瓶颈QPS, 网络瓶颈QPS)
容量规划黄金法则：先做业务分类，再做流量建模，最后反推节点规格与数量。不要先选节点再适配业务。
3.4 业务需求分析流程总览
下图展示了从需求收集到集群规划的完整链路：
3.5 实战案例：电商平台需求分析
以日活100万的电商平台为例，展示需求分析到集群规划的映射：
| 业务模块 | 应用类型 | 流量模型 | 资源需求 | 规划建议 |
|---|---|---|---|---|
| 商品详情页 | 无状态 | 潮汐型（白天高、夜间低） | 200 Pod × 0.5C/1G | HPA + Cluster Autoscaler |
| 订单服务 | 有状态 | 突发型（秒杀时暴涨10倍） | 50 Pod × 1C/2G + MySQL集群 | StatefulSet + PVC + PDB |
| 数据报表 | 批处理 | 定时型（每日凌晨） | 20 Pod × 2C/4G | CronJob + 独立节点池 |
容量估算示例：商品详情页200 Pod，每Pod 0.5C/1G，冗余系数1.5，则总需求为150C/300G。若选用8C/32G节点，约需19个节点（150/8=18.75），考虑系统开销和DaemonSet，建议规划22~25个节点。
通过以上步骤，业务需求被转化为可执行的集群规划参数，为后续的节点选型、网络设计、存储方案和弹性策略奠定基础。