00 前言

把一个 RKE2 集群从几十节点做到几千节点，不是"把同样的操作重复一千遍"，而是一套完全不同的工程体系：架构要重新设计、配置要重新调优、运维要流程化、观测要平台化、优化要数据驱动。本书讲的就是这套体系。

---

大规模集群的特殊性

当集群规模从百节点迈向数千节点，量变引发质变：

维度	百节点	数千节点
etcd	默认参数即可	DB 大小、碎片、磁盘延迟成为生死线
apiserver	单点也能扛	必须水平扩展 + APF 流控 + watch 治理
网络	iptables 够用	iptables 规则爆炸，IPVS/eBPF 成为必选项
DNS	CoreDNS 2 副本	必须 NodeLocal DNSCache + 自动扩缩
升级	周末批量做完	必须分批灰度，一次升级持续数周
监控	一个 Prometheus	指标基数爆炸，必须 Thanos/VictoriaMetrics
故障	单点故障	批量故障、级联故障、惊群效应成为常态

本书的核心观点是：大规模集群的稳定性不是靠"不出问题"，而是靠"出了问题有体系兜底"——容量有规划、变更有灰度、监控有告警、故障有预案、优化有基线。

全书主线

架构设计（第一部分）→ 配置与部署（第二部分）→ 运维体系（第三部分）
        → 可观测性（第四部分）→ 性能优化（第五部分）→ 案例与最佳实践（第六部分）

五维一体，环环相扣：架构决定上限，配置决定基线，运维决定底线，观测决定能见度，优化决定效率。

使用方法

1. 顺序阅读：第一遍按顺序通读，建立体系认知。
2. 按需查阅：附录的速查表适合放在手边随用随查。
3. 案例驱动：第六部分的 15 个故障案例建议在测试环境复现几个（尤其是 etcd 相关），大规模故障的肌肉记忆只能练出来。
4. 保守原则：书中所有推荐值均为保守起点，落地前必须结合自己的压测数据调整——先度量，再优化。

实验环境建议

环境	规模	用途
6~10 台 VM	3 server + 3~7 agent	验证配置、演练升级与恢复
（可选）kubemark	模拟数千空心节点	控制平面压测

真实数千节点环境难以在实验室复现，本书第五部分介绍的 kube-burner + kubemark 是验证控制平面容量的现实手段。

现在，从 第一部分 数千节点架构设计与容量规划 开始。