Kubernetes etcd 详解 以及 etcd数据同步的核心原理

于 2025-06-07 00:14:24 发布
阅读量664 收藏 19
点赞数 9
分类专栏： k8s 文章标签： kubernetes etcd 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/csdn_tom_168/article/details/148478769
版权

(一) Kubernetes etcd 详解

etcd 是 Kubernetes 的核心组件之一，作为分布式键值存储系统，它负责存储 Kubernetes 集群的所有配置数据和状态信息。etcd 是 Kubernetes 的“大脑”，所有集群状态（如节点、Pod、Service、ConfigMap、Secret 等）都存储在 etcd 中。

一、etcd 的核心作用

  1. 存储 Kubernetes 集群状态：
    • 存储所有 Kubernetes 资源（Pod、Service、Deployment、ConfigMap、Secret 等）的配置和状态。
  2. 分布式一致性：
    • etcd 采用 Raft 共识算法，保证多节点数据一致性和高可用性。
  3. 集群协调：
    • 控制平面组件（如 kube-apiserver、kube-scheduler、kube-controller-manager）依赖 etcd 进行数据同步和状态管理。
  4. 高可用性：
    • etcd 通常以集群模式运行（3 或 5 节点），确保数据不丢失。

二、etcd 的架构

1. etcd 的核心组件

组件作用
etcd Server存储和提供键值数据，运行 Raft 协议保证一致性
etcd Client提供 API 接口（如 HTTP/gRPC），供 Kubernetes 控制平面访问
Raft 协议保证分布式一致性，选举 Leader 节点

2. etcd 的数据存储

  • 键值存储：
    • 所有 Kubernetes 资源以键值对形式存储（如 /registry/pods/default/my-pod）。
  • 版本控制：
    • 每个键值对都有版本号，支持历史记录查询。
  • TTL（Time-To-Live）：
    • 支持设置键的过期时间（常用于临时数据）。

三、etcd 与 Kubernetes 的关系

1. etcd 存储的关键数据

Kubernetes 资源etcd 存储路径示例
Pod/registry/pods/<namespace>/<pod名>
Service/registry/services/specs/<namespace>/<service名>
Deployment/registry/deployments/<namespace>/<deployment名>
ConfigMap/registry/configmaps/<namespace>/<configmap名>
Secret/registry/secrets/<namespace>/<secret名>
Node/registry/nodes/<节点名>

2. etcd 的访问方式

  • kube-apiserver 是唯一直接访问 etcd 的组件：
    • 其他控制平面组件（如 kube-scheduler、kube-controller-manager）通过 kube-apiserver 间接访问 etcd。
  • etcdctl：
    • 可以直接使用 etcdctl 命令行工具操作 etcd（需权限）。

四、etcd 的高可用部署

1. etcd 集群模式

  • 推荐部署方式：
    • 生产环境至少部署 3 节点（奇数节点，保证多数派投票）。
    • 可以部署在独立的机器或与控制平面组件（kube-apiserver、kube-controller-manager、kube-scheduler）共存。
  • etcd 集群通信：
    • 节点之间通过 gRPC 通信，使用 Raft 协议选举 Leader。

2. etcd 的备份与恢复

（1）备份 etcd 数据
# 使用 etcdctl 备份（需 etcdctl 版本与集群一致）
ETCDCTL_API=3 etcdctl --endpoints=https://<etcd节点IP>:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot.db
（2）恢复 etcd 数据
# 停止 etcd 服务
systemctl stop etcd

# 清空 etcd 数据目录（默认 /var/lib/etcd）
rm -rf /var/lib/etcd/*

# 恢复快照
ETCDCTL_API=3 etcdctl --data-dir=/var/lib/etcd \
  snapshot restore /backup/etcd-snapshot.db \
  --data-dir=/var/lib/etcd

# 启动 etcd
systemctl start etcd

五、etcd 的安全配置

1. etcd 的认证与授权

  • TLS 加密通信：
    • etcd 默认使用 TLS 加密客户端与服务器之间的通信。
    • 配置文件示例（etcd.conf）：
      [member]
name="etcd-node1"
client-cert-auth=true
trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
cert-file=/etc/kubernetes/pki/etcd/server.crt
key-file=/etc/kubernetes/pki/etcd/server.key
  • 客户端认证：
    • 可以配置 client-cert-auth=true，要求客户端提供证书认证。

2. etcd 的访问控制

  • RBAC（基于角色的访问控制）：
    • Kubernetes 的 kube-apiserver 可以限制哪些组件可以访问 etcd。
    • 例如，只允许 kube-apiserver 访问 etcd，禁止其他组件直接访问。

六、etcd 的监控与维护

1. 监控 etcd 的健康状态

# 检查 etcd 集群健康状态
ETCDCTL_API=3 etcdctl --endpoints=https://<etcd节点IP>:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

# 查看 etcd 集群成员
ETCDCTL_API=3 etcdctl --endpoints=https://<etcd节点IP>:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list

2. etcd 的性能优化

  • 调整 etcd 的配置参数：
    • --snapshot-count：控制快照频率（默认 10 万次写入触发一次快照）。
    • --quota-backend-bytes：限制 etcd 存储大小（默认 2GB）。
  • 监控 etcd 的指标：
    • 使用 Prometheus + Grafana 监控 etcd 的延迟、磁盘使用率等指标。

七、etcd 的常见问题与解决方案

1. etcd 集群无法选举 Leader

  • 可能原因：
    • 节点网络分区（部分节点无法通信）。
    • 磁盘空间不足。
    • etcd 配置错误（如 --initial-cluster 配置错误）。
  • 解决方案：
    • 检查网络连通性（ping 或 telnet）。
    • 清理磁盘空间（df -h 检查磁盘使用率）。
    • 检查 etcd 配置文件（/etc/etcd/etcd.conf）。

2. etcd 数据损坏

  • 可能原因：
    • 磁盘故障。
    • 强制终止 etcd 进程。
  • 解决方案：
    • 从备份恢复 etcd 数据（参考第四部分）。
    • 如果没有备份，可能需要重建集群（数据会丢失）。

3. etcd 性能下降

  • 可能原因：
    • 存储数据量过大（超过 --quota-backend-bytes 限制）。
    • 磁盘 I/O 性能差。
  • 解决方案：
    • 清理无用数据（如旧的 ConfigMap、Secret）。
    • 升级磁盘（SSD 比 HDD 性能更好）。

八、etcd 的最佳实践

  1. 生产环境必须使用 etcd 集群：
    • 至少 3 节点（奇数节点，保证多数派投票）。
  2. 启用 TLS 加密：
    • 防止数据泄露和中间人攻击。
  3. 定期备份 etcd 数据：
    • 至少每周备份一次，存储在安全位置（如异地存储）。
  4. 监控 etcd 的健康状态：
    • 使用 Prometheus + Grafana 监控 etcd 的延迟、磁盘使用率等指标。
  5. 限制 etcd 的访问权限：
    • 只允许 kube-apiserver 访问 etcd，禁止其他组件直接访问。

九、总结

特性说明
etcd 的作用存储 Kubernetes 集群的所有配置和状态数据
etcd 的架构分布式键值存储，基于 Raft 协议保证一致性
etcd 的高可用生产环境至少 3 节点，支持备份与恢复
etcd 的安全TLS 加密通信，RBAC 访问控制
etcd 的监控监控健康状态、性能指标（延迟、磁盘使用率）
etcd 的最佳实践生产环境必须使用集群，启用 TLS，定期备份

关键点：

  • etcd 是 Kubernetes 的“大脑”，所有集群状态都存储在 etcd 中。
  • 生产环境必须使用 etcd 集群（至少 3 节点），并启用 TLS 加密。
  • 定期备份 etcd 数据，防止数据丢失。
  • 监控 etcd 的健康状态和性能，确保集群稳定运行。

(二) etcd 集群节点之间的数据同步机制

etcd 采用 Raft 共识算法 实现分布式一致性，确保集群中所有节点的数据同步。以下是 etcd 节点间数据同步的核心机制和流程：

一、etcd 数据同步的核心原理

1. Raft 共识算法

  • 作用：保证分布式系统中多个节点的数据一致性，即使部分节点故障也能正常运行。
  • 关键角色：
    • Leader：负责处理所有写请求，并将数据同步到 Follower 节点。
    • Follower：接收 Leader 的数据同步请求，并返回确认（ACK）。
    • Candidate：在 Leader 选举时临时担任的角色（用于选举新的 Leader）。

2. 数据同步流程

  1. 客户端写入数据：

    • 客户端向 etcd 集群发送写请求（如创建/修改键值对）。
    • 请求会被发送到当前 Leader 节点（如果是 Follower，则会重定向到 Leader）。

  2. Leader 处理写请求：

    • Leader 将写请求转换为 Raft 日志条目（Log Entry），并追加到自己的日志中。
    • Leader 将该日志条目发送给集群中的所有 Follower 节点（通过 RPC 请求）。

  3. Follower 确认写入：

    • Follower 接收 Leader 的日志条目后，会先写入自己的日志（但不立即应用）。
    • Follower 返回 ACK（确认） 给 Leader，表示已收到日志条目。

  4. Leader 提交日志：

    • 当 Leader 收到多数派（Quorum）Follower 的 ACK 后，会将该日志条目标记为 已提交（Committed）。
    • Leader 将提交的数据应用到自己的状态机（即实际存储到 etcd 的键值存储中）。

  5. Follower 应用提交的数据：

    • Follower 在收到 Leader 的提交通知后，也会将对应的日志条目应用到自己的状态机。
    • 此时，所有节点的数据保持一致。

二、etcd 数据同步的关键机制

1. 日志复制（Log Replication）

  • 作用：确保所有节点的日志一致。
  • 流程：
    1. Leader 将写请求转换为 Raft 日志条目。
    2. Leader 将日志条目发送给 Follower。
    3. Follower 将日志条目写入自己的日志（但暂不应用）。
    4. 当多数 Follower 确认后，Leader 提交日志，并通知 Follower 应用。

2. 心跳机制（Heartbeat）

  • 作用：维持 Leader 的权威性，检测节点是否存活。
  • 流程：
    • Leader 定期向 Follower 发送 心跳消息（AppendEntries RPC）。
    • 如果 Follower 在一定时间内未收到心跳，则认为 Leader 失效，触发 Leader 选举。

3. Leader 选举（Leader Election）

  • 作用：当 Leader 失效时，选举新的 Leader。
  • 流程：
    1. Follower 在未收到心跳时，会将自己的状态切换为 Candidate。
    2. Candidate 向其他节点发送 投票请求（RequestVote RPC）。
    3. 如果获得多数票（Quorum），则成为新的 Leader。
    4. 新 Leader 开始处理写请求，并同步数据到 Follower。

4. 数据一致性保证

  • 强一致性（Strong Consistency）：
    • etcd 保证所有节点的数据最终一致（即使网络分区或节点故障）。
    • 写入操作只有在多数节点确认后才会提交，确保数据不会丢失。

三、etcd 数据同步的详细步骤（以写操作为例）

  1. 客户端发送写请求：

    • 客户端向 etcd 集群发送 PUT /key value 请求。
    • 请求会被路由到当前 Leader 节点（如果是 Follower，则会重定向到 Leader）。

  2. Leader 处理写请求：

    • Leader 将写请求转换为 Raft 日志条目（如 {"key":"my-key","value":"my-value"}）。
    • Leader 将日志条目追加到自己的日志中，并发送给所有 Follower。

  3. Follower 确认写入：

    • Follower 接收日志条目后，写入自己的日志（但暂不应用）。
    • Follower 返回 ACK 给 Leader。

  4. Leader 提交日志：

    • 当 Leader 收到多数 Follower 的 ACK 后，标记该日志条目为 已提交。
    • Leader 将数据应用到自己的状态机（实际存储到 etcd 的键值存储中）。

  5. Follower 应用数据：

    • Follower 在收到 Leader 的提交通知后，将对应的日志条目应用到自己的状态机。
    • 此时，所有节点的数据保持一致。

四、etcd 数据同步的故障处理

1. Leader 失效

  • 检测：
    • Follower 在一定时间内未收到 Leader 的心跳，则认为 Leader 失效。
  • 处理：
    • Follower 切换为 Candidate，发起 Leader 选举。
    • 新 Leader 选举成功后，继续处理写请求并同步数据。

2. 网络分区（Network Partition）

  • 情况：
    • 集群被分成多个子集群（部分节点无法通信）。
  • 处理：
    • 每个子集群会选举自己的 Leader（可能导致脑裂）。
    • etcd 通过 Quorum 机制 防止脑裂（只有多数节点组成的子集群才能选举 Leader）。

3. 节点故障恢复

  • 故障节点重新加入：
    • 故障节点恢复后，会从当前 Leader 同步缺失的日志条目。
    • Leader 会发送缺失的日志给故障节点，使其数据与集群一致。

五、etcd 数据同步的关键配置参数

参数作用默认值
--heartbeat-intervalLeader 发送心跳的间隔时间100ms
--election-timeoutFollower 等待心跳的超时时间（触发选举）1s
--snapshot-count触发快照的日志条目数（减少日志大小）10万
--quota-backend-bytesetcd 存储的最大数据量（防止磁盘耗尽）2GB

六、总结

特性说明
数据同步机制基于 Raft 共识算法，Leader 处理写请求并同步到 Follower
核心流程写入 → Leader 复制日志 → Follower 确认 → Leader 提交 → Follower 应用
一致性保证强一致性（多数节点确认后才提交）
故障处理Leader 失效时选举新 Leader，网络分区时防止脑裂
关键配置heartbeat-interval、election-timeout、snapshot-count

关键点：

  • etcd 使用 Raft 算法 保证数据同步和一致性。
  • 写入操作需要 多数节点确认 才能提交，确保数据不会丢失。
  • Leader 失效时，集群会自动选举新 Leader，保证高可用性。
万字详解：etcd、HBase 与 Redis 技术原理对比与应用场景选型 & 用生活实例讲透技术本质与应用
AI天才研究院
04-13 137
Redis：内存型键值数据库，注重极高的读写性能etcd：分布式键值存储，注重一致性和可靠性HBase：分布式列族数据库，注重海量数据的可扩展存储选择 Redis 的场景需要极高的读写性能（亚毫秒级响应）数据量相对较小，可以放入内存需要复杂的数据结构（如列表、集合、有序集合等）典型用例：缓存、会话存储、排行榜、计数器、实时分析选择 etcd 的场景需要强一致性保证的小型关键数据服务发现和注册分布式系统的配置管理分布式锁和领导者选举。
深入理解与管理Kubernetes中的核心组件etcd
lhq1363511234的博客
04-09 657
etcd是一个开源的分布式键值对存储系统，巧妙地运用Raft一致性算法来确保其在分布式环境中的数据一致性与可靠性。在Kubernetes体系中，etcd充当了一个集群级别的元数据仓库，其中存储了包括Pods、Services、ReplicaSets等各种对象信息，以及各个节点的状态和详细配置。
Kubernetes之etcd：详解与实践
qq_44342036的博客
03-13 1139
例如，所有 Pod 相关的数据可以存储在 /pods 目录下，所有 Service 相关的数据可以存储在 /services 目录下。任期编号单调递增，用于区分不同的时间段。Leader 向所有 Follower 发送 AppendEntries RPC，请求它们将新的日志条目追加到自己的日志中。Leader 将已提交的日志条目应用到自己的状态机（State Machine），执行客户端请求的操作。优化：etcd 定期生成 快照（Snapshot），将当前状态机的数据保存到磁盘，并清理旧的日志条目。
Kubernetes(十三)etcd详解
liu_weiliang10405的博客
04-03 1446
导读：etcd 是用于共享配置和服务发现的分布式、一致性的 KV 存储系统。本文从 etcd 项目发展所经历的几个重要时刻开始，为大家介绍了 etcd 的总体架构及其设计中的基本原理。希望能够帮助大家更好的理解和使用 etcd。 一、etcd 项目的发展历程 etcd 诞生于 CoreOS 公司，它最初是用于解决集群管理系统中 OS 升级的分布式并发控制以及配置文件的存储与分发等问题。基于此，etcd 被设计为提供高可用、强一致的小型 keyvalue 数据存储服务。 项目当前隶属于 CNCF 基金会
Kubernetes 之 详解Etcd集群
weixin_33979203的博客
03-05 806
前言随着kubernetes项目的日益火热，该项目中用到的etcd组件作为一个高可用强一致性的服务发现存储仓库，渐渐的被开发人员所关注。在云计算时代，如何让服务快速、透明的接入到计算集群中，如何让共享配置信息快速被集群中的所有节点发现，如何构建一套高可用、安全、易于部署以及快速响应的服务集群成为了需要解决的问题。Etcd为解决这类问题带来便捷。官方地址：https://co...
k8s的核心组件etcd功能详解【含etcd各类参数详细说明】
热门推荐
崔崇鑫的博客，你linux/云运维工作中的百科全书。
08-16 1万+
文章目录Kubernetes的核心组件ETCD介绍ETCD的主要功能特点【优点】Etcd集群中的术语Etcd的架构与术语流程分析Etcd主要分为四个部分【http server、store、raft、WAL】工作原理及RAFT算法详解Leader选举：包括Raft 状态机和Raft算法中的Term（任期）两部分。Raft 状态机1、Leader(领导者):2、Follower(跟随者):3、Candidate(候选者):Raft算法中的Term（任期）日志复制【数据复制】安全性【数据安全】etcd应用场景服
etcd详解
技术人集结地
05-31 832
摘要 etcd是一个高可用的分布式键值存储系统，基于Raft共识算法确保数据强一致性。它具有键值存储、Watch监听、租约机制等核心特性，广泛应用于服务发现、配置管理、分布式锁等场景。作为Kubernetes的核心组件，etcd存储集群状态和配置数据。其架构包含Leader/Follower角色，使用BoltDB和WAL实现数据持久化。运维时需关注集群部署、性能优化、监控和备份恢复。相比ZooKeeper和Consul，etcd在云原生领域表现突出，提供简洁API和可靠存储方案。
Kubernetes核心组件-ETCD详解
weixin_49925141的博客
02-19 1821
Kubernetes是典型的主从分布式架构，由集中式管理节点（Master Node）,分布式的工作节点（Worker Node）组成以及辅助工具组成。其中ETCD是管理节点的核心组件，主要负责集群状态集中式存储，功能架构与Zookeeper类似。本篇主要是详细讲解ETCD架构及核心技术。 ETCD发展与演进 ETCD是用Go语言编写，通过Raft一致性算法，实现的一个高可用的分布式键值(key-value)数据库，核心里程碑如下： 2013年6月，由C...
Kubernetes控制平面组件：etcd常用配置参数
a1369760658的博客
02-16 969
本文主要介绍 Etcd 的常用配置，包括：成员参数、集群参数、安全参数、灾备参数、容量管理参数 和 碎片整理参数，并对核心参数进行讲解
Kubernetes 控制平面组件：etcd
一点一滴铺就人生
08-21 1770
基于Raft协议的kubernetes高性能键值对数据库！
etcd原理
Flytiger
03-28 3116
etcd简介 ETCD是用于共享配置和服务发现的分布式，一致性的KV存储系统。它是一个优秀的高可用分布式键值对存储数据库。etcd内部采用了Raft协议作为一致性算法，且使用Go实现。 ETCD作为一个受到ZooKeeper与docker启发而催生的项目，除了拥有与之类似的功能外，更专注于以下四点： 简单：基于HTTP+JSON的API让你用curl就可以轻松使用。 安全：可选SSL客户认证机制。 快速：每个实例每秒支持一千次写操作。 可信：使用Raft算法充分实现了分布式。 分布式系统中的数据分
k8s学习笔记（5）--- kubernetes核心组件之etcd详解
梦谜的博客
12-29 4506
kubernetes核心组件之etcd详解一、etcd二、etcd部署1.采用etcd镜像的方式部署1.1 将服务器添加进集群的两种方式1.1.1 将服务器挨个添加进集群 一、etcd         etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 Zo...
Kubernetes入门详解
HB199753的博客
12-14 1736
一、Kubernetes 1、为什么要有K8s 在看这段文字之前，我们要首先知道一个东西，那就是docker。 这里再简单的说下： docker是容器技术的一种实现方案，同时docker也是docker公司的一个产品。目前主流的容器技术是以docker技术为标准之上的。使用docker可以无需考虑环境问题，docker可以一次构建，到处运行。 如果有很多容器需要管理，单纯使用docker命令来手动管理容器就会显得非常的麻烦，并且容易出错。docker公司提供了docker-compose和内置dock
k8s热更新-subPath 不支持热更新
西京刀客
06-04 672
使用 subPath 存在一个容易踩坑的问题：热更新（文件在宿主或 PVC 中发生变化，容器内不会感知）。实在有 subPath 的场景，**通过重启 Pod 方式实现刷新挂载**。
【信创-k8s】海光/兆芯+银河麒麟V10离线部署k8s1.31.8+kubesphere4.1.3
qq_33174891的博客
06-03 932
介于V4优秀的LuBan架构，核心组件非常少，资源占用也显著降低，同时带来众多功能和便利性。：使用海光3350/兆芯开先KX-5000芯片，麒麟V10 SP3操作系统，以及Containerd 1.7.13、Kubernetes v1.31.8、KubeSphere v4.1.3等软件版本。原创编写，详细记录了从环境准备到平台验证的完整流程，为信创环境下的Kubernetes与KubeSphere部署提供了参考。转载请获取作者同意。：登录KubeSphere管理界面，检查集群状态和节点信息，确保部署成功。
Docker_Desktop开启k8s
晓的博客
06-05 492
在Docker Desktop中启用Kubernetes服务，需先修改Docker Engine配置并添加镜像源。从GitHub下载k8s-for-docker-desktop项目，执行load_images脚本后，在Docker设置中启用Kubernetes并重启。接着部署Dashboard资源，通过kubectl proxy访问。获取登录Token时若提示没有默认secret，可使用kubectl列出所有secret并获取正确名称，或直接创建有效期为8760小时的token。最终访问地址为：http:/
kubeadm安装k8s
chanfi_dong的博客
06-06 332
kubeadm部署k8s
k8s开发webhook使用certmanager生成证书
小诸葛的博客
06-05 244
【代码】k8s开发webhook使用certmanager生成证书。
如何使用k8s安装redis呢
最新发布
曼陀罗的博客
06-06 479
本文介绍了在Kubernetes上安装Redis的三种方法：1) 使用StatefulSet直接部署，需要创建ConfigMap、StatefulSet和Service；2) 通过Helm chart快速部署Bitnami Redis，支持主从配置；3) 完整部署方案，包含PersistentVolume和PersistentVolumeClaim配置确保数据持久化。每种方法都提供了详细的YAML配置示例，涵盖镜像拉取（ARM/x86）、密码设置、存储配置等关键步骤，并包含部署验证命令。特别针对生产环境需求
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值