2. 单Master架构：拓扑结构、适用场景与局限性分析
单Master架构是Kubernetes控制面最简部署形态，所有控制面组件（API Server、Controller Manager、Scheduler、etcd）均运行在同一节点上。该架构常用于开发、测试及学习环境，但在生产环境中存在显著的单点故障风险。
2.1 拓扑结构
单Master架构中，控制面组件与etcd存储共置于一台物理机或虚拟机。工作节点（Worker Nodes）通过kubelet与API Server通信，所有调度决策、控制器循环和状态持久化均依赖单一控制面节点。
核心组件部署关系：
- API Server (kube-apiserver) — 暴露RESTful API，作为集群入口。
- Controller Manager (kube-controller-manager) — 运行节点控制器、副本控制器、端点控制器等。
- Scheduler (kube-scheduler) — 将Pod调度到合适的Worker Node。
- etcd — 键值存储，保存集群所有状态数据。
2.2 适用场景
单Master架构主要面向非生产环境，以下场景最为常见：
| 场景 | 说明 | 推荐理由 |
|---|---|---|
| 本地开发环境 | 开发者个人笔记本或工作站上运行Kubernetes | 资源消耗低，启动快，便于调试 |
| CI/CD测试流水线 | 自动化测试集群，用于验证应用部署与功能 | 临时集群，生命周期短，无需高可用 |
| Kubernetes学习实验 | 初学者练习kubectl命令、Pod编排、Service暴露等 | 架构简单，易于理解控制面组件交互 |
| 功能原型验证 (PoC) | 快速搭建集群验证新特性或Operator | 部署时间短，运维成本低 |
实践建议： 使用
minikube、kind (Kubernetes in Docker) 或 k3s 快速搭建单Master集群。这些工具默认采用单节点控制面，适合上述场景。
2.3 局限性分析
单Master架构在生产环境中存在以下关键局限性：
- 单点故障 (SPOF) — Master节点宕机将导致整个集群不可用。API Server不可响应，调度器无法分配新Pod，Controller Manager无法执行修复操作。
- etcd单实例风险 — etcd是集群状态的核心存储，单实例故障将导致数据丢失或集群脑裂。生产环境要求etcd集群至少3个节点。
- 控制面性能瓶颈 — 所有API请求、调度计算、控制器循环均集中在一台机器上。随着集群规模增长（超过50-100个节点），API Server响应延迟显著增加。
- 滚动更新与维护困难 — 升级kube-apiserver、kube-scheduler或etcd版本时，必须停机操作，无法实现零停机升级。
- 资源争抢 — 控制面组件与etcd共享CPU、内存和磁盘IO。高负载下，etcd写入延迟可能影响调度和控制器性能。
2.4 关键指标对比
以下表格从可用性、性能、运维三个维度对比单Master与多Master架构：
| 维度 | 单Master | 多Master (HA) |
|---|---|---|
| 可用性 (SLA) | 无保障，单节点故障即集群不可用 | 99.9%+，支持故障自动转移 |
| 最大节点规模 | 建议 ≤ 50 个Worker节点 | 官方支持 5000 节点 |
| etcd写入延迟 (P99) | 受单机磁盘IO影响，通常 < 10ms | 集群写入，Leader选举增加少量延迟 |
| API Server吞吐 | 单实例，约 5000 req/s | 多实例负载均衡，线性扩展 |
| 升级策略 | 停机升级，业务中断 | 滚动升级，逐个节点替换 |
| 资源开销 | 低 (2-4 vCPU, 4-8 GB RAM) | 高 (每Master 4-8 vCPU, 8-16 GB RAM) |
生产环境警告： 切勿将单Master架构用于承载真实业务流量。即使集群规模很小（3-5个Worker节点），也建议至少部署3个控制面节点配合etcd集群。单Master架构在Master节点宕机后，恢复时间通常需要30分钟以上（重建组件、恢复etcd快照），对业务影响极大。
2.5 部署示例（快速搭建）
使用 kubeadm 初始化单Master集群的命令如下：
# 在Master节点执行
kubeadm init --pod-network-cidr=10.244.0.0/16
# 配置kubectl
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config
# 安装Pod网络插件（以Flannel为例）
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# 查看集群状态
kubectl get nodes
kubectl get pods -n kube-system上述命令将启动一个单Master集群，所有控制面组件以静态Pod形式运行在 kube-system 命名空间。该集群适合功能验证，但不应作为生产环境长期运行。