K8s 整体架构
K8s 采用经典的主从架构，分为 Master 节点（控制平面）和 Worker 节点（数据平面）。
Master 节点组件
API Server
集群的统一入口，所有组件（kubectl、Dashboard、其他组件）都通过 API Server 与集群通信：
# kubectl 命令实际是向 API Server 发送 HTTP 请求
kubectl get pods
# 等价于
curl -k https://master-ip:6443/api/v1/namespaces/default/pods
bash
核心功能：
- RESTful API 接口
- 认证、授权、准入控制
- 所有状态变更的入口
- 唯一直接与 etcd 通信的组件
etcd
分布式键值存储，保存集群的所有状态数据：
| 特性 | 说明 |
|---|---|
| 一致性算法 | Raft 协议 |
| 推荐实例数 | 3 或 5 个（奇数个） |
| 数据持久化 | 所有集群配置、状态数据 |
| 备份建议 | 定期执行 etcdctl snapshot save |
Controller Manager
运行各种控制器，每个控制器是一个独立的控制循环：
- Deployment Controller：管理 Deployment 和 ReplicaSet
- ReplicaSet Controller：确保 Pod 副本数符合预期
- Node Controller：监控节点健康状态
- Service Account Controller：管理服务账户
Scheduler
将未调度的 Pod 分配到合适的 Worker 节点。调度决策考虑因素：
- 资源需求（CPU、内存）
- 亲和性/反亲和性规则
- 节点选择器（Node Selector）
- 污点和容忍（Taints and Tolerations）
Worker 节点组件
kubelet
每个 Worker 节点上运行的代理：
- 从 API Server 获取该节点上的 Pod 规格
- 通过容器运行时（containerd/docker）启动容器
- 执行存活探针和就绪探针检查
- 向 API Server 报告节点和 Pod 状态
kube-proxy
管理节点上的网络规则：
- iptables 模式：通过 iptables 规则实现 Service 的负载均衡
- IPVS 模式：通过 IPVS（内核级虚拟服务器）实现，性能更高
- 负责将 Service 的 ClusterIP 请求转发到后端 Pod
容器运行时
负责运行容器的软件：
| 运行时 | 接口 | 特点 |
|---|---|---|
| containerd | CRI | 推荐方案，轻量高性能 |
| Docker + cri-dockerd | CRI | 需要额外的 CRI 适配层 |
| CRI-O | CRI | 专为 K8s 设计 |
组件通信流程
kubectl apply -f deployment.yaml
│
▼
API Server → 验证请求 → 写入 etcd
│
▼
Controller Manager → 检测到新 Deployment → 创建 ReplicaSet → 创建 Pod（未调度）
│
▼
Scheduler → 检测到未调度 Pod → 选择合适节点 → 更新 Pod 的 nodeName
│
▼
kubelet (目标节点) → 检测到新 Pod → 调用容器运行时 → 启动容器
│
▼
kube-proxy → 检测到新 Pod → 更新网络规则（iptables/IPVS）
text
高可用架构要点
生产环境建议的 Master 节点配置：
| 组件 | 高可用方案 |
|---|---|
| API Server | 多实例 + 负载均衡（HAProxy/keepalived） |
| etcd | 3 或 5 节点集群（Raft 协议保证一致性） |
| Controller Manager | 多实例，通过 leader election 选举主节点 |
| Scheduler | 多实例，通过 leader election 选举主节点 |
↑