2025-04-19    2025-04-19    1972 字  4 分钟
k8s

Kubernetes (K8s) 选择 etcd 作为其默认的分布式键值存储（Key-Value Store）核心组件，主要基于以下关键设计特性和实际需求：

1. 强一致性与高可靠性

  • Raft 共识算法：etcd 使用 Raft 实现强一致性（CP 系统），确保集群中所有节点的数据一致，这对 K8s 的 控制平面（如调度、配置、状态管理）至关重要。
  • 数据持久化：etcd 支持持久化存储，即使节点重启也能恢复数据，保障 K8s 集群状态的可靠性。

2. 高性能与低延迟

  • 读写优化：etcd 针对读多写少的场景（如 K8s 频繁查询 Pod 状态）优化，支持每秒数万次读写操作。
  • 低延迟响应：通过 Raft 的 Leader 节点处理写请求，减少分布式协商开销，满足 K8s 对实时性的要求（如快速响应 kubectl 命令）。

3. Watch 机制（事件监听）

  • 核心功能：etcd 提供高效的 Watch API，K8s 利用它监听资源变更（如 Pod 创建/删除），触发控制器（Controller）的协调逻辑（Reconcile）。
  • 事件驱动架构：这是 K8s 实现声明式 API 和自动化运维的基础。

4. 简单清晰的 API 设计

  • 键值存储模型：etcd 的简单 KV 接口（如 Put/Get/Delete）与 K8s 的资源存储需求高度匹配。
  • 事务支持：支持原子事务操作，适合 K8s 需要同时更新多个资源的场景（如 Deployment 和 ReplicaSet 联动）。

5. 社区与生态集成

  • CNCF 项目：etcd 和 K8s 同属 CNCF 项目，协同开发和维护，确保兼容性。
  • 广泛验证：etcd 在大型生产环境中久经考验（如 Google、AWS 等），稳定性有保障。

6. 安全性

  • TLS 加密：支持客户端与集群间的加密通信，符合 K8s 对安全通信的要求。
  • RBAC 集成：与 K8s 的 RBAC 系统无缝对接，精细化控制访问权限。

对比其他数据库为何不选？

  • ZooKeeper：虽然类似，但 ZooKeeper 的 ZAB 协议和复杂 API 不如 etcd 轻量。
  • Consul：更侧重服务发现，KV 存储性能不如 etcd 专注。
  • MySQL/PostgreSQL：关系型数据库的强一致性代价高，且缺乏原生 Watch 机制。

潜在挑战

  • 运维复杂度：etcd 需要单独维护（备份、扩缩容等），高可用部署需谨慎。
  • 存储限制：默认适合存储元数据，不适合大规模非结构化数据（需配合其他存储方案）。

总结

etcd 凭借 强一致性、高性能、事件监听 等特性，成为 K8s 存储集群状态的理想选择，两者共同构建了云原生基础设施的基石。

为什么不是redis呢

1. 数据一致性与可靠性

  • etcd：
    • 基于 Raft 共识算法，是 强一致性（CP） 系统，确保数据在分布式环境中绝对一致。
    • 所有写入必须经过多数节点确认，适合存储 集群关键状态（如 Pod 调度、节点状态）。
  • Redis：
    • 默认是 内存数据库，虽然支持持久化（AOF/RDB），但设计更偏向 高性能（AP） 而非强一致性。
    • 集群模式（Redis Cluster）使用 异步复制，可能丢失最新写入数据（脑裂风险），不适合 K8s 对可靠性的要求。

👉 K8s 需要绝对可靠的状态存储，不能容忍数据不一致或丢失。

2. Watch 机制（事件监听）

  • etcd：
    • 原生支持高效的 长连接 Watch API，K8s 控制器（Controller）依赖它实时监听资源变更（如 Pod 创建/删除）。
    • 事件是有序且可靠的，确保 K8s 控制循环（Control Loop）正确触发。
  • Redis：
    • 提供 PUB/SUB 或 Keyspace Notifications，但它们是 瞬时、无持久化 的。如果客户端断开连接，会丢失事件。
    • 缺乏全局事件序列号，难以保证事件顺序。

👉 K8s 的声明式 API 和控制器逻辑严重依赖可靠的 Watch 机制。

3. 事务与原子操作

  • etcd：
    • 支持 多键事务（Transactional API），例如原子化更新多个资源（如同时更新 Deployment 和 ReplicaSet）。
  • Redis：
    • 虽然支持 MULTI/EXEC 事务，但本质是 乐观锁，且仅限单节点。集群模式下跨分片事务复杂。

👉 K8s 需要跨资源原子操作（如滚动更新），Redis 难以满足。

4. 存储模型与性能

  • etcd：
    • 基于 持久化键值存储，数据最终落盘，适合存储元数据（如 Pod 配置）。
    • 读性能优化（支持线性一致性读）。
  • Redis：
    • 核心是 内存数据库，虽然快但容量受限于内存，持久化可能影响性能。
    • 存储大规模元数据（如 10 万个 Pod 定义）成本高昂。

👉 K8s 需要持久化存储大量元数据，而非缓存。

5. 社区与生态集成

  • etcd：
    • 与 K8s 同属 CNCF 项目，深度集成，API 设计高度匹配（如 gRPC 接口）。
  • Redis：
    • 更侧重缓存和实时数据处理，缺乏对 K8s 生态的原生支持。

6. 安全与多租户

  • etcd：
    • 支持 细粒度 RBAC（基于 K8s ServiceAccount 的权限控制）。
  • Redis：
    • 权限模型简单（密码认证），难以实现 K8s 复杂的多租户需求。

为什么有人会想到 Redis？

  • 误解场景：Redis 适合 缓存、会话存储、消息队列，而 K8s 需要的是 持久化、强一致的状态存储。
  • 临时尝试：小规模实验性项目可能用 Redis 模拟 etcd，但生产环境会暴露一致性问题。

总结

特性 etcd Redis
一致性 强一致性（CP） 最终一致性（AP）
持久化 默认持久化 可选持久化（性能折衷）
Watch 机制 可靠、有序的事件流 瞬时、不可靠的事件通知
事务支持 跨键原子事务 单节点简单事务
设计目标 分布式系统元数据存储 高性能缓存/实时数据处理

K8s 选择 etcd 的根本原因：它是专为分布式系统元数据存储设计的，而 Redis 是为完全不同的场景优化的。