总结：K8s之Etcd - 迅博思语资讯移动站

总结：K8s之Etcd

2024-10-31 21:27

简介

Etcd是CoreOS基于Raft协议开发的分布式key-value存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。

总结：K8s之Etcd

如，Etcd也可以作为微服务的注册中心，比如SpringCloud也基于ETCD实现了注册中心功能，可以替代earka，具体参考：Spring Cloud Etcd

在分布式系统中，如何管理节点间的状态一直是一个难题，etcd是专门为集群环境的服务发现和注册而涉及，它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。

Etcd被形容为Kubernetes集群的大脑，是 Kubernetes的关键组件，因为它存储了集群的整个状态：其配置，规格以及运行中的工作负载的状态。

在Kubernetes世界中，etcd用作服务发现的后端，并存储集群的状态及其配置。

Etcd被部署为一个集群，几个节点的通信由Raft算法处理。在生产环境中，集群包含奇数个节点，并且至少需要三个。

特点

etcd作为一个受到ZooKeeper与doozer启发而催生的项目，除了拥有与之类似的功能外，更专注于以下四点。

简单：基于HTTP+JSON的API让你用curl就可以轻松使用。
安全：可选SSL客户认证机制。
快速：每个实例每秒支持一千次写操作。
可信：使用Raft算法充分实现了分布式。

简单：curl可访问的用户的API（HTTP + JSON）

安全：可选的SSL客户端证书认证

快速：单实例每秒1000次写操作

可靠：使用Raft算法保证一致性

主要功能

1. 基本的key-value存储

2. 监听机制

3. key的过期及续约机制，用于监控和服务发现

4. 原子Compare And Swap和Compare And Delete, 用于分布式锁和leader选举

架构

基础模块介绍

client 层：包含 client v2 和 v3 两个大版本 API 客户端
API 网络层：主要包含 client 访问 server 和 server 节点之间的通信协议。client 访问 server 分为两个版本：v2 API 采用 HTTP/1.x 协议，v3 API 采用 gRPC 协议。server 之间的通信：是指节点间通过 Raft 算法实现数据复制和 Leader 选举等功能时使用的 HTTP 协议
Raft 算法层：实现了 Leader 选举、日志复制、ReadIndex 等核心算法特性，用于保障 etcd 多节点间的数据一致性、提升服务可用性等，是 etcd 的基石和亮点
功能逻辑层：etcd 核心特性实现层。如典型的 KVServer 模块、MVCC 模块、Auth 鉴权模块、Lease 租约模块、Compactor 压缩模块等，其中 MVCC 模块主要有 treeIndex 模块和 boltdb 模块组成
存储层：包含预写日志 WAL 模块、快照 Snapshot 模块、 boltdb 模块，其中 WAL 可保障 etcd crash 后数据不丢失，boltdb 则保存了集群元数据和用户写入的数据。

数据写入流程

client 发起一个更新 hello 为 world 请求后

若 Leader 收到写请求，它会将此请求持久化到 WAL 日志，并广播给各个节点

a. 若一半以上节点持久化成功，则该请求对应的日志条目被标识为已提交

b. 之后，etcdserver 模块异步从 Raft 模块获取已提交的日志条目，应用到状态机（boltdb等）

参考下图：

关于 etcd

本文的主角是 etcd。名称 “etcd” 源自两个想法，即 unix “/etc” 文件夹和 “d” 分布式系统。“/etc” 文件夹是用于存储单个系统的配置数据的位置，而 etcd 用于存储大规模分布式的配置信息。因此，分配了 “d” 的 “/etc” 就是 “etcd”。

etcd 被设计为大型分布式系统的通用基板。这些大型系统需要避免脑裂问题，并且愿意牺牲可用性来实现此目的。 etcd 以一致且容错的方式存储元数据。 etcd 集群旨在提供具有稳定性、可靠性、可伸缩性和性能的键值存储。

分布式系统将 etcd 用作配置管理、服务发现和协调分布式工作的一致键值存储组件。许多组织在生产系统上使用 etcd，例如容器调度程序、服务发现服务和分布式数据存储。使用 etcd 的常见分布式模式包括领导者选举、分布式锁和监视机器活动状态等。

脑裂

即两个机房网络中断，导致每个机房都会选出自己的leader。

解决方案：引入“过半概念”，投票选举，只有经过过半数的同意票才能够被选举为leader。那么网络故障致使的分区问题解决了，可是它的限制也很明显就是若是出现过半的机器宕机，会致使整个集群没法正常提供服务数

与 ZooKeeper

ZooKeeper 解决了与 etcd 相同的问题：分布式系统协调和元数据存储。但是， etcd 踩在前人的肩膀上，其参考了 ZooKeeper 的设计和实现经验。从 Zookeeper 汲取的经验教训无疑为 etcd 的设计提供了支撑，从而帮助其支持 Kubernetes 等大型系统。对 Zookeeper 进行的 etcd 改进包括：

动态重新配置集群成员
高负载下稳定的读写
多版本并发控制数据模型
可靠的键值监控
租期原语将 session 中的连接解耦
用于分布式共享锁的 API

此外，etcd 开箱即用地支持多种语言和框架。Zookeeper 拥有自己的自定义Jute RPC 协议，该协议对于 Zookeeper 而言是完全唯一的，并限制了其受支持的语言绑定，而 etcd 的客户端协议则是基于 gRPC 构建的，gRP 是一种流行的 RPC 框架，具有 go，C ++，Java 等语言支持。同样，gRPC 可以通过 HTTP 序列化为 JSON，因此即使是通用命令行实用程序（例如curl）也可以与之通信。由于系统可以从多种选择中进行选择，因此它们是基于具有本机工具的 etcd 构建的，而不是基于一组固定的技术围绕 etcd 构建的。

在考虑功能，支持和稳定性时，etcd 相比于 Zookeeper，更加适合用作一致性的键值存储的组件。

在Kubernetes集群的上下文中，etcd实例可以作为Pod部署在master节点上（这是我们将在本文中使用的示例）。

为了增加安全性和弹性，还可以将其部署为外部集群。

以下来自Heptio博客的序列图显示了在简单的Pod创建过程中涉及的组件。它很好地说明了API服务器和etcd的交互作用。

参考：etcd的安装与命令行使用-蒲公英云

我们一般需要看etcd的数据来验证自己的功能，比如Grafana Mimir中etcd替换memberlist，要验证是否替换成功，得要看下etcd中的数据，所以我们就涉及到看数据，看数据的话可以使用UI客户端，或者命令行。

找了几个UI客户端，发现要账号密码，但是我们的etcd集群需要ca证书验证，于是想试试命令行方式，etcd安装参见安装。

安装后的效果如下：

etcdctl --endpoints=$ENDPOINTS --ca-file=/data/weiwei/helm-ww/helm-mimir/etcd/ca.pem --cert-file=/data/weiwei/helm-ww/helm-mimir/etcd/client.pem --key-file=/data/weiwei/helm-ww/helm-mimir/etcd/client-key.pem member list

奇怪，后来上面的命令又提示Error: unknown flag: --ca-file

改了下命令：etcdctl --endpoints=$ENDPOINTS --cacert=/data/weiwei/helm-ww/helm-mimir/etcd/ca.pem --cert=/data/weiwei/helm-ww/helm-mimir/etcd/client.pem --key=/data/weiwei/helm-ww/helm-mimir/etcd/client-key.pem member list