集群基础架构：节点角色划分、网络拓扑与存储选型
大家好，我是你们的老朋友。今天咱们聊聊集群的骨架——基础架构。
很多人一上来就撸起袖子装Kubernetes，结果跑了两天发现网络不通，或者存储跟不上。嗯，我当年也干过这种事。后来才明白，基础架构没想清楚，后面全是坑。
这一章，我会把节点角色、网络拓扑、存储选型这三件事掰开揉碎了讲。你想想看，这三样东西就像盖房子的地基、水电和承重墙——缺一个都不行。
一、节点角色划分：Master 与 Worker 的职责边界
集群里的节点，说白了就两种角色：Master（控制节点）和 Worker（工作节点）。
我个人的习惯是，先把它们当成两个人：
- Master 是大脑，负责决策、调度、监控。
- Worker 是手脚，负责跑任务、存数据。
千万别让大脑去干体力活。我在项目中遇到过有人把数据库直接跑在 Master 节点上，结果一次高负载把 etcd 搞崩了，整个集群瘫痪。嗯，血的教训。
Master 节点核心组件
| 组件 | 职责 | 个人建议 |
|---|---|---|
| etcd | 集群状态存储 | 单独部署，IO敏感 |
| kube-apiserver | 所有请求入口 | 多副本，负载均衡 |
| kube-scheduler | Pod调度决策 | 资源预留要充足 |
| kube-controller-manager | 控制器循环 | 与apiserver同节点 |
关键原则：Master 节点不要运行业务 Pod。我曾经见过有人为了省机器，把监控系统也塞到 Master 上，结果 etcd 写延迟飙升到 200ms。集群直接进入只读模式。
Worker 节点设计要点
- 资源隔离：系统预留资源（kubelet、OS）要算清楚。我一般留 10% 给系统。
- 标签管理：给 Worker 打上 GPU、SSD、高内存等标签。方便调度。
- 污点与容忍：特殊节点（比如 GPU 节点）要加污点，防止普通 Pod 跑上去。
小技巧：我习惯把 Master 节点数设为奇数（3 或 5）。etcd 的 Raft 协议需要多数派存活，奇数节点能最大化容错率。3 个 Master 可以挂 1 个，5 个可以挂 2 个。
二、网络拓扑设计：扁平还是分层？
网络拓扑这块，说白了就是解决两个问题：Pod 之间怎么通信，以及集群外部怎么访问。
我见过最惨的案例：有人用了三层交换机做 Overlay 网络，结果 MTU 没配好，导致跨节点通信频繁丢包。查了三天才发现是 MTU 不一致。所以，网络设计一定要从底层想清楚。
常见的网络模型
| 模型 | 特点 | 适用场景 |
|---|---|---|
| 扁平网络（Flannel） | 简单、性能好 | 中小集群，<100节点 |
| Overlay（Calico） | 支持网络策略 | 需要安全隔离的场景 |
| Underlay（Macvlan） | 性能接近物理机 | 高性能计算、NFV |
我个人比较推荐 Calico。为什么？因为它支持 NetworkPolicy，能精细控制 Pod 之间的流量。你想想看，金融场景下，A 业务和 B 业务必须隔离，没有网络策略根本没法搞。
网络拓扑设计原则
- 控制平面与数据平面分离：Master 节点走管理网络，Worker 节点走业务网络。别混在一起。
- 带宽规划：我一般建议业务网络至少 10Gbps。存储网络如果走独立链路，建议 25Gbps 起步。
- 延迟敏感：etcd 集群节点之间的延迟不要超过 10ms。否则 Raft 心跳会超时。
注意：千万不要把集群网络和办公网络混在一起。我曾经见过有人把 Kubernetes API 暴露在办公网，结果被内部扫描工具扫到，引发安全事件。集群网络应该是一个独立的、受控的 VLAN。
网络拓扑示意图
下面这张图展示了典型的集群网络拓扑。你可以看到 Master 和 Worker 分别接入不同的网络平面。
三、存储架构选型：本地盘、NAS 还是分布式？
存储这块，水很深。我做了这么多年运维，见过太多因为存储选型翻车的案例。
说白了，存储选型就三个维度：性能、容量、可用性。你不可能三角全占满，必须做取舍。
主流存储方案对比
| 方案 | 性能 | 可用性 | 成本 | 推荐场景 |
|---|---|---|---|---|
| 本地 SSD | 极高 | 低（单点） | 中 | 缓存、临时数据 |
| NFS / NAS | 中 | 高（双控） | 中高 | 共享存储、传统应用 |
| Ceph | 中高 | 极高（多副本） | 高 | 大规模、统一存储 |
| Longhorn | 中 | 高 | 低 | Kubernetes 原生 |
我个人比较推荐 Longhorn。为什么？因为它跟 Kubernetes 集成得最好，而且不需要额外的硬件。你想想看，用 Ceph 还得搭 MON、OSD、MGR 一堆组件，Longhorn 直接跑在 Worker 节点上，省心不少。
避坑指南：我曾经在一个项目中选了 NFS 作为持久化存储。结果业务高峰期，NFS 服务器成了瓶颈，所有 Pod 都在等 IO。后来换成 Longhorn，每个节点本地读写，性能提升了 3 倍。嗯，共享存储不是万能的。
存储选型决策树
- 需要高性能？ → 本地 SSD + 应用层副本
- 需要共享读写？ → NFS 或 CephFS
- 需要块存储？ → Longhorn 或 Ceph RBD
- 需要对象存储？ → MinIO 或 Ceph RGW
我的经验：对于数据库类应用（MySQL、PostgreSQL），我建议用本地 SSD + 定期备份。不要用共享存储，因为数据库对延迟极其敏感。对于日志、文件等场景，用分布式存储更合适。
存储性能测试小工具
选型之前，一定要做性能测试。我常用的工具是 fio：
# 测试随机写延迟
fio --name=randwrite --ioengine=libaio --rw=randwrite \
--bs=4k --size=1G --numjobs=1 --runtime=60 \
--group_reporting
# 测试顺序读吞吐
fio --name=seqread --ioengine=libaio --rw=read \
--bs=1M --size=10G --numjobs=4 --runtime=60 \
--group_reporting跑完测试，看看 99 分位延迟。如果超过 10ms，那这个存储方案就不适合跑数据库。
小结
这一章我们聊了三件事：
- 节点角色：Master 管控制，Worker 管业务。别混用。
- 网络拓扑：控制平面和数据平面分离。带宽要够，延迟要低。
- 存储选型：没有银弹。根据场景选，测试后再上线。
嗯，基础架构这块，说白了就是「想清楚再动手」。我见过太多人因为着急上线，跳过这些设计步骤，最后花三倍的时间来填坑。你想想看，是花一周设计好，还是花一个月返工？
下一章我们会深入聊聊集群安装和配置。不过在那之前，先把今天的内容消化掉。有什么问题，欢迎随时交流。