Cluster Architecture 集群架构
整个集群架构分为Control Plane和Node Components两大部分。
Control Plane
控制面共有5个组件，4个核心组件+1个可选组件
kube-apiserver
Kube-apiserver 是Kubernetes control plane控制面的front end，对外暴露Kubernetes API；
kube-controller-manager
Kueb-controller-manager 是Kubernetes 的"通用大脑"，处理所有云无关的核心逻辑；
cloud-controller-manaer
Cloud-ctrontroller-manger 是"云接口适配器"，专门负责与云厂商 API 交互。两者通过职责分离实现云中立架构，使 Kubernetes 能在任意环境运行，同时无缝对接主流云平台；
etcd
Etcd K-V数据库，是分布式系统的"协调大脑"，用强一致性保障关键元数据安全（如 Kubernetes 集群状态）；
同是K-V数据库，对比Redis
一致性与可靠性
- etcd：写入需经 Raft 多数派共识，保证所有节点数据严格一致（线性一致性）
→ 适合不能容忍数据不一致的场景（如分布式锁、集群元数据）
- Redis：主节点写入即返回，异步复制到从节点
→ 可能存在短暂数据不一致，但延迟极低（微秒级）
数据模型对比
| 基础类型 | 仅 key → byte[]（二进制安全） | String、Hash、List、Set、Sorted Set、Bitmap 等 redis.io |
|---|---|---|
| 目录结构 | 支持 / 分隔的层级键（如 /services/web/instances） | 无原生目录，需自行设计 key 命名 |
| TTL | ✅ 支持（lease 机制） | ✅ 支持（EXPIRE 命令） |
| 事务 | ✅ 支持（Compare-And-Swap） | ✅ 支持（MULTI/EXEC） |
| Watch 机制 | ✅ 原生可靠事件通知（基于 Raft 日志）www.lixueduan.com | ⚠️ 需 Pub/Sub（不保证可靠，可能丢消息） |
💡 关键差异： etcd 的 Watch 机制 是其核心优势——客户端可订阅 key 变化，etcd 通过 Raft 日志顺序 保证事件不丢失、不重复
知乎
，而 Redis Pub/Sub 是"尽力而为"的发布订阅，不保证可靠性。
性能特性
| 指标 | etcd | Redis |
|---|---|---|
| 写入延迟 | 毫秒级（需网络往返 + Raft 共识） | 微秒级（内存操作 + 异步持久化） |
| 读取延迟 | 毫秒级（线性一致性读需多数派确认） | 微秒级（直接内存访问） |
| 吞吐量 | 中等（~10k ops/s，3 节点集群） | 极高（~100k+ ops/s） |
| 持久化 | 默认开启（WAL + Snapshot） | 可选（RDB 快照 / AOF 日志） |
⚠️ 实测对比：
- Redis 读写速度相近（均 ~7μs）
- itnext.io
- etcd 写入较慢（需共识），但读取可优化（通过
quorum=false启用本地读）- itnext.io
高可用架构
| 组件 | etcd | Redis |
|---|---|---|
| 集群模式 | 原生 Raft 集群（3/5/7 节点） | Sentinel（哨兵）或 Cluster（分片） |
| 故障恢复 | 自动选主（Raft Leader Election） | Sentinel 手动/自动故障转移 |
| 脑裂处理 | Raft 天然防脑裂（需多数派） | 可能脑裂（需配置 min-slaves-to-write） |
| 数据安全 | 写入即持久化（WAL） | 可能丢失（取决于 AOF/RDB 配置） |
Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
kubelet
kubelet 是 Kubernetes 节点（Node）上的核心代理（Agent），直接运行在每个工作节点上，负责：
将 PodSpec（Pod 定义）转化为实际运行的容器，并持续保障容器状态与期望状态一致 —— 它是 Kubernetes 控制平面与容器运行时之间的唯一桥梁，也是节点上唯一直接与容器打交道的组件。
| 1.Pod 生命周期管理 | 创建/启动/停止/删除容器 | 通过 CRI（Container Runtime Interface） 调用 containerd/docker |
|---|---|---|
| 2. 状态同步 | 持续上报 Node/Pod 状态到 API Server | 定期 NodeStatus 更新 + PodStatus 上报 |
| 3. 卷管理 | 挂载/卸载存储卷（PV/PVC） | 调用 Volume Plugins（in-tree/out-of-tree CSI） |
| 4. 网络配置 | 为 Pod 配置网络（IP/路由） | 调用 CNI 插件（Calico/Flannel 等） |
| 5. 健康检查 | 执行 Liveness/Readiness/Startup Probe | HTTP/TCP/Exec 探针 + 重启策略 |
| 6. 资源管理 | 保障 QoS（Guaranteed/Burstable/BestEffort） | cgroups 限制 + OOM Killer 优先级 |
Container runtime
Container-runtime 是 Kubernetes 节点上负责“创建、运行、管理容器进程”的底层引擎，它是 kubelet 与操作系统之间的桥梁，将 PodSpec 转化为真实的容器进程。
| 镜像管理 | 拉取/存储/删除容器镜像（ImageService） |
|---|---|
| 容器生命周期 | 创建/启动/停止/删除容器（RuntimeService） |
| 资源隔离 | 通过 cgroups + namespaces 实现进程隔离与资源限制 |
kube-proxy
kube-proxy 是 Kubernetes 节点上的网络代理，负责将 ClusterIP 类型的 Service 流量转发到后端 Pod，实现服务发现与负载均衡。
Addons
Addons（附加组件）是运行在 Kubernetes 集群内部、提供核心功能之外增强能力的 Pod/Service 组合。
它们不是 Kubernetes 核心组件（如 kube-apiserver/etcd），但对生产环境至关重要。
| 部署位置 | 运行在集群内部（kube-system 或专用 namespace） |
|---|---|
| 依赖关系 | 依赖 Kubernetes API，但不参与集群控制平面 |
| 可选性 | 理论上可不安装，但生产环境几乎必需 |
| 部署方式 | 通过 Deployment/DaemonSet + Service + RBAC 部署 |
| 生命周期 | 由 Kubernetes 自身管理（自托管） |
常见 Addons 分类与示例
| 类别 | 典型 Addons | 作用 | 是否必需 |
|---|---|---|---|
| 集群 DNS | CoreDNS / kube-dns | 为 Service/Pod 提供域名解析（*.svc.cluster.local） | ✅ 必需（无 DNS 服务发现失效） |
| 网络插件 | Cilium / Calico / Flannel | 实现 Pod 网络通信（CNI） | ✅ 必需（无 CNI Pod 无法启动） |
| Metrics | Metrics Server | 提供资源指标（kubectl top / HPA 依赖） | ⚠️ 推荐（HPA/监控必需） |
| Ingress Controller | Nginx Ingress / Istio Gateway | 7 层 HTTP 路由（替代 NodePort/LoadBalancer） | ⚠️ 推荐（生产环境暴露服务必需） |
| Dashboard | Kubernetes Dashboard | Web UI 管理界面 | ❌ 可选（运维便利性） |
| 存储驱动 | CSI Drivers（AWS EBS / Azure Disk） | 挂载云存储卷 | ⚠️ 按需（有状态应用必需） |
| 监控 | Prometheus Operator / Grafana | 集群监控与告警 | ⚠️ 推荐（生产环境必需） |
| 服务网格 | Istio / Linkerd | 流量管理、安全、可观测性 | ⚠️ 按需（微服务架构推荐） |
💡 关键区分：
- 核心组件：kube-apiserver/kube-controller-manager/kube-scheduler/etcd/kubelet —— 集群启动必需
- Addons：CoreDNS/Cilium/Metrics Server —— 集群启动后部署，但生产环境必需
