33. K8s 核心组件讲解——etcd

本章讲解知识点

etcd 概述
Raft 原理简介
etcd 其他应用场景

<br>

etcd 不算 Kubernetes 自研组件，etcd 自身是一个开源组件，Kubernetes 集成了它而已。但我们还是有必要讲讲 etcd。

1. etcd 概述

1.1 概述

etcd 是一个高可用的分布式键值存储系统，被用来存储 Kubernetes 集群中的所有配置数据和状态信息。etcd 具有高可用、强一致性和快速响应等特性，可以保证 Kubernetes 集群的数据可靠性和一致性。

1.2 etcd 特点

键值对存储：将数据存储在分层组织的目录中，如同在标准文件系统中
监测变更：监测特定的键或目录以进行更改，并对值的更改做出反应
简单：curl 可访问的用户的 API (HTTP + JSON)
安全：可选的 SSL 客户端证书认证
快速：单实例每秒 1000 次写操作，2000+ 次读操作
可靠：基于 Raft 共识算法，实现分布式系统内部数据存储、服务调用的一致性和高可用性

1.3 etcd 主要功能

基本的 key-value 存储
监听机制（Watch）：监测特定的键或目录以进行更改，并对值的更改做出反应。watch 机制支持 watch 某个固定的 key，也支持一个范围 (前缀机制)。当监听的 key 或者范围发生变化时，客户端将收到通知
原子 Compare And Swap 和 Compare And Delete，用于分布式锁和 leader 选举
Revision 机制：每个 Key 带有一个 Revision 号，每进行一次事务便加一，因此它是全局唯一的，如初始值为 0，进行一次 Put 操作，Key 的 Revision 变为 1，同样的操作，再进行一次，Revision 变为 2；换成 Key1 进行 Put 操作，Revision 将变为 3。这种机制有一个作用，即通过 Revision 的大小就可知道写操作的顺序，这对于实现公平锁，队列十分有益；
Lease 机制：即租约机制（TTL，Time To Live），Etcd 可以为存储的 Key-Value 对设置租约，当租约到期，Key-Value 将失效删除；同时也支持续约，通过客户端可以在租约到期之前续约，以避免 Key-Value 对过期失效；此外，还支持解约，一旦解约，与该租约绑定的 Key-Value 将失效删除；

1.4 应用场景

etcd 在稳定性、可靠性和可伸缩性上表现极佳，同时也为云原生应用系统提供了协调机制。etcd 经常用于服务注册与发现的场景，此外还有键值对存储、消息发布与订阅、分布式锁等场景。

1.5 键值对存储

etcd 是一个用于键值（Key-Value）存储的组件，存储是 etcd 最基本的功能，其他应用场景都建立在 etcd 的可靠存储上。比如 Kubernetes 将一些元数据存储在 etcd 中，将存储状态数据的复杂工作交给 etcd，Kubernetes 自身的功能和架构就能更加稳定。

etcd 是一个分布式键值存储数据库，常用于存储 Kubernetes 集群的配置信息。以下是一个 etcd 中键值对存储的示例：

/registry/namespaces/default
{
    "metadata": {
        "name": "default",
        "selfLink": "/api/v1/namespaces/default",
        "uid": "06f94ec9-6b20-49a2-9865-1f465c75be28",
        "resourceVersion": "1066415",
        "creationTimestamp": "2023-04-20T12:34:56Z",
        "labels": {
            "name": "default"
        }
    },
    "spec": {},
    "status": {}
}

这是一个描述 Kubernetes 中 default 命名空间的 etcd 键值对。其中 /registry/namespaces/default 是键，对应的值是一个 JSON 格式的对象，包含了该命名空间的元数据（metadata）、规范（spec）和状态（status）信息。元数据包括命名空间的名称、UID、创建时间、标签等；规范和状态信息则根据不同的资源对象而有所不同。

1.6 etcd 架构

HTTP Server: 提供数据读写功能，监听服务端口；用于处理用户发送的 API 请求。以及其他 etcd 节点的数据同步和心跳信息请求
Raft：Raft 强一致性算法的具体实现，etcd 的核心。
Store：用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、时间处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现
WAL：Write Ahead Log (预写式日志)，是 etcd 的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd 就通过 WAL 进行持久化存储。WAL 中，所有数据提交前都会实现记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容

通常，一个用户的请求发送过来，会经由 HTTP Server 转发给 Store 进行具体的事务处理。如果涉及到节点的修改，则交给 Raft 模块进行仲裁和日志记录 ，然后再同步给别的 etcd 节点以确认数据提交，只有当半数以上的节点确认了该节点状态修改之后，才会真正进行数据的提交（持久化），然后再次同步。

<br>

2. Raft 原理简介

2.1 分布式系统的数据一致性问题

Raft 是一种更为简单方便易于理解的分布式算法，主要解决了分布式中的数据一致性问题。分布式系统的数据一致性问题是指在分布式系统中，多个节点之间共享数据时可能会因为网络延迟、节点故障等原因导致数据不一致的情况。在分布式系统中，由于数据存储在不同的节点上，节点之间的通信需要经过网络，因此在数据更新过程中，可能会存在网络分区、节点故障等情况，导致不同节点上的数据出现不一致。

2.2 名词解释

Raft协议一共包含如下 3 类角色：

Leader（领袖）：领袖由群众投票选举得出，每次选举，只能选出一名领袖；
Candidate（候选人）：当没有领袖时，某些群众可以成为候选人，然后去竞争领袖的位置；
Follower（群众）：这个很好理解，就不解释了。

然后在进行选举过程中，还有几个重要的概念：

Leader Election（领导人选举）：简称选举，就是从候选人中选出领袖；
Term（任期）：它其实是个单独递增的连续数字，每一次任期就会重新发起一次领导人选举；
Election Timeout（选举超时）：就是一个超时时间，当群众超时未收到领袖的心跳时，会重新进行选举。

2.3 角色转换

群众 -> 候选人：当开始选举，或者“选举超时”时候选人 -> 候选人：当“选举超时”，或者开始新的“任期”候选人 -> 领袖：获取大多数投票时候选人 -> 群众：其它节点成为领袖，或者开始新的“任期”领袖 -> 群众：发现自己的任期 ID 比其它节点分任期 ID 小时，会自动放弃领袖位置

2.4 动画详解

通过动画详细学习：

http://thesecretlivesofdata.com/raft/

为了保证数据的强一致性，etcd 集群中所有的数据流向都是一个方向，从 Leader 节点流向 Follower，也就是 Follower 的数据必须与 Leader 一致，如果不一致会被覆盖。简单点说，用户可以对 etcd 集群中的所有节点进行读写。首先读取非常简单，因为每个节点保存的数据是强一致的。对于写入来说，etcd 集群中的节点会选举 Leader 节点，如果写入请求来自 Leader 节点，则可以直接写入，然后 Leader 会把写入分发给所有 Follower；如果写请求来自其他 Follower 节点，那么写入请求会转发给 Leader 节点，有 Leader 节点写入之后再分发给集群中的所有节点。

<br>

3. etcd 其他应用场景

etcd 被用来存储 Kubernetes 集群中的所有配置数据和状态信息，这是 etcd 作为 Kubernetes 集群中的重要组件之一主要功能。但是 etcd 还有其他能力被用作其他场景，我们也有必要简要介绍一下。

3.1 服务注册与发现

etcd 基于 Raft 算法，能够有力地保证分布式场景中的一致性。各个服务启动时注册到 etcd 上，同时为这些服务配置键的 TTL 时间。注册到 etcd 上面的各个服务实例通过心跳的方式定期续租，实现服务实例的状态监控。

服务发现（Service Discovery）要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。服务发现的实现原理如下。

存在一个高可靠、高可用的中心配置节点：基于 Ralf 算法的 etcd 天然支持。
服务提供方会持续的向配置节点注册服务：用户可以在 etcd 中注册服务，并且对注册的服务配置租约，定时续约以达到维持服务的目的（一旦停止续约，对应的服务就会失效）。
服务的调用方会持续地读取中心配置节点的配置并修改本机配置，然后 Reload 服务：服务提供方在 etcd 指定的目录（前缀机制支持）下注册服务，服务调用方在对应的目录下查询服务。通过 watch 机制，服务调用方还可以监测服务的变化。