关于云计算:揭秘KubeSphere-背后的超级大脑etcd-的魅力与力量

8次阅读

共计 6953 个字符，预计需要花费 18 分钟才能阅读完成。

作者：尹珉，KubeSphere Ambassador & Contributor，KubeSphere 社区用户委员会杭州站站长。

在云原生时代，etcd 作为 Kubernetes 生态中不可或缺的外围组件，扮演着 KubeSphere 集群“神经系统”的角色。它利用 Raft 一致性算法提供弱小的分布式键值存储能力，确保集群状态信息的实时同步和长久化。

每当在 KubeSphere 中执行资源操作时，这些指令首先通过 etcd 进行解决和散发，从而实现对整个集群状态的刹时更新与治理。正是因为 etcd 的存在，KubeSphere 才得以在大规模容器编排中展示卓越的性能和稳定性。

接下来，咱们将深刻摸索 etcd 如何奇妙地融入 KubeSphere 生态系统，并通过理论利用场景展现其对晋升平台工作效率和可靠性的关键作用。

etcd 的旅程始于 2013 年 CoreOS 团队的一项翻新尝试，随着其 V1 和 V2 版本的倒退，逐步奠定了在分布式系统数据一致性解决方案中的位置。从 etcd V1、V2 到 V3 版本的迭代过程中，性能一直晋升，稳定性日益加强，性能上也不断丰富和欠缺。

经验数次重要降级后，etcd V3 版本尤其显著地解决了 Kubernetes 倒退过程中面临的存储瓶颈问题。在性能方面，通过优化实现了更快的数据读写速度；在稳定性上，引入了更为强壮的一致性保障机制；在性能上，则扩大了 API 接口，加强了安全性与可管理性。

因而，etcd 凭借这些改良，在性能、稳定性和性能上的卓越体现胜利保卫了作为 Kubernetes 外围存储组件的位置，并在云原生时代中扮演着不可或缺的角色，继续推动整个生态系统的提高与倒退。

etcd 是典型的读多写少存储，理论业务场景中，读个别占据 2/3 以上的申请。为了让大家对 etcd 每个模块有肯定的初步理解，简略介绍一下每个模块的性能作用。

Client 层：etcd 提供了 v2 和 v3 两个版本的 API 客户端库，通过负载平衡、节点故障主动转移等机制简化了业务集成过程，无效晋升了开发效率与服务稳定性。
API 网络层：该层解决客户端与服务器以及服务器间的通信。v2 API 基于 HTTP/1.x 协定，而 v3 API 则应用 gRPC 协定，并通过 grpc-gateway 反对 HTTP/1.x 调用以满足多语言需要。此外，Raft 一致性算法驱动下的服务器间通信也采纳 HTTP 协定来实现数据复制和 Leader 选举等性能。
Raft 算法层：这一要害层实现了诸如 Leader 选举、日志复制及 ReadIndex 等外围个性，确保了 etcd 集群中多个节点间的数据一致性和高可用性。
性能逻辑层：在此层面上，etcd 的外围模块包含 KV 存储、多版本并发管制（MVCC）、权限验证（Auth）、租约治理（Lease）以及数据压缩（Compactor）等组件，其中 MVCC 模块由 treeIndex 和 boltdb 组成，用于高效且平安地解决键值操作。
存储层：为保证数据安全性与长久化，存储层蕴含预写日志（WAL）和快照（Snapshot）机制，以及用于存储元数据和用户数据的 boltdb 数据库。WAL 避免 etcd 在解体后失落数据，而 boltdb 则负责理论的数据存储与检索。

秘诀就是 Raft 算法，旨在简化分布式系统中的共识问题了解与实现。它将简单的共识过程合成为三个关键环节：

Leader 选举：确保在 Leader 节点生效时能疾速从新选举出新的 Leader。
日志复制：通过仅容许 Leader 节点写入日志，并负责向 Follower 节点复制日志记录，以保障集群外部数据一致性。
安全性：在安全性方面，Raft 算法设计了严格的规定，例如一个任期内仅产生一个无效的 Leader、先前已提交的日志条目在新 Leader 上必然存在，且所有节点的状态机利用的雷同地位应具备雷同的日志内容。这一系列机制独特保障了分布式系统的稳定性和一致性。

在分布式系统背景下，看似简略的数据读取操作实则蕴含简单机制。对于 etcd 这类谋求高可用与强一致性的键值存储系统，每一次读申请均是对底层技术细节和算法智慧的深度实际。面对大规模集群环境，当客户端发送读取指令时，etcd 如何确保疾速精确地响应呢？接下来，咱们一起揭示 etcd 读申请背地的核心技术流程。

客户端发动申请：利用通过 etcd 的 v2 或 v3 版本 API 客户端库发送读取键值对的申请，反对 HTTP/1.x 和 gRPC 协定。
Raft 算法交互：对于读操作，etcd 采纳 ReadIndex 机制。客户端将读申请发送至以后 Leader 节点，Leader 节点先记录下这次读申请，而后在提交一个新的日志条目后，再响应客户端的读申请，确保在此期间没有新的写入导致集群状态扭转。
一致性保障：Leader 节点依据 Raft 算法确保所有已提交的日志条目已被集群内所有 Follower 节点复制，并达到统一状态。
KV 存储查问：Leader 节点从外部 MVCC（多版本并发管制）模块中的 boltdb 数据库中检索对应键的最新无效版本数据。
返回后果：一旦获取到数据，Leader 节点将后果返回给客户端，实现读取操作。

在深入探讨 etcd 的读流程时，咱们涉及到了其外围机制——线性读与串行读。这两种读模式别离应答不同的一致性需要场景。接下来，咱们只对它们的含意做一个简略的解释：

串行读（Serializable Read）实用于对数据实时性要求不严苛的状况，间接从节点状态机中获取数据，实现低提早、高吞吐，但可能存在肯定的数据一致性危险。
线性读（Linearizable Read）则是为了满足要害业务操作对强一致性的需要，确保任何更新后的值都能被后续申请及时精确地拜访到，即便集群中有多个节点，客户端通过线性读也能如同拜访繁多节点般取得最新且已达成共识的数据。只管相比串行读可能带来更高的延时和较低的吞吐，但在要求严格数据一致性的场景下，线性读是 etcd 默认且现实的读取形式。

KubeSphere 是在 Kubernetes 之上构建的面向云原生利用的分布式操作系统，齐全开源，反对多云与多集群治理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。它的架构能够十分不便地使第三方利用与云原生生态组件进行即插即用 (plug-and-play) 的集成。

KubeSphere 将前端与后端离开，实现了面向云原生的设计，后端的各个性能组件可通过 REST API 对接内部零碎。可参考 API 文档。下图是零碎架构图。KubeSphere 无底层的基础设施依赖，能够运行在任何 Kubernetes、公有云、私有云、VM 或物理环境（BM）之上。此外，它能够部署在任何 Kubernetes 发行版上。

KubeKey 由 Go 语言开发，应用便捷、轻量，反对多种支流 Linux 发行版。KubeKey 反对多种集群部署模式，例如 All-in-One、多节点、高可用以及离线集群部署。KubeKey 也反对疾速构建离线安装包，减速离线交付场景下的集群交付效率。KubeKey 实现多节点并行装置，且利用 Kubeadm 对集群和节点进行初始化，极大地节俭了集群部署工夫，同时也遵循了 Kubernetes 社区支流集群部署办法。KubeKey 提供内置高可用模式，反对一键部署高可用 Kubernetes 集群。

为了演示成果应用 all-in-one 疾速部署。

export KKZONE=cn

curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.13 sh -

chmod +x kk

./kk create cluster --with-kubernetes v1.22.12 --with-kubesphere v3.4.1

应用 KubeKey 部署集群会默认装置 etcdctl。

https://github.com/etcd-io/etcd/releases  #自行下载

tar -zxvf etcd-v3.5.11-linux-amd64.tar.gz

cp etcdctl /usr/local/bin/

阐明：KubeKey 装置集群时默认 etcd 应用二进制装置，证书门路默认在此处。

/etc/ssl/etcd/ssl

通过采纳 KubeKey 工具施行最小化部署案例，展现了如何使用平安证书机制来实现对 etcd 的拜访以监控集 etcd 服务状态。只管此处演示以繁多实例出现，但在理论生产环境中，etcd 服务必然是基于高可用集群模式运行，始终坚守着高可靠性的外围准则。

为保障 etcd 性能，举荐应用 SSD 硬盘，并通过工具（如 fio）进行磁盘速度评估。倡议系统配置至多与默认存储配额（2GB）相等的 RAM，个别举荐 8GB 以上以防止性能降落。典型部署中，etcd 集群应在具备双核 CPU、2GB 内存和 80GB SSD 的专用服务器上运行。请依据理论工作负载对硬件配置进行调整并事后测试，确保生产环境性能达标。

etcd 集群达成状态更新共识须要少数节点参加，即至多（n/2）+1 个成员在具备 n 个节点的集群中。对于奇数节点数量的集群，减少一个节点虽外表上加强了零碎规模，但实际上升高了容错性：雷同数量节点故障时仍能放弃仲裁，但更多节点故障可能导致仲裁失落。因而，在集群无奈容忍额定故障且新节点可能注册失败的状况下，贸然增加节点是危险的，因为这可能导致永久性的仲裁损失。

实践上，etcd 集群规模无明确下限，但实际中举荐不超过 7 个节点。参照 Google 外部宽泛部署的 Chubby 锁服务教训，倡议维持 5 节点配置。这样的集群能容忍两个成员故障，通常已满足需要。只管更大集群晋升容错性，但会因数据在更多节点上的复制而导致写入性能降落。

在构建和运维 etcd 集群时，监控是确保业务稳定性和提前辨认危险的关键步骤。

etcd 提供了泛滥 metrics，按模块划分包含磁盘、网络、MVCC 事务、gRPC RPC 和 etcdserver 等外围指标，用于展现集群健康状况。为了无效监控这些指标，举荐应用 Prometheus 服务采集 etcd 2379 端口的 metrics 数据，并可通过动态或动静配置实现。

动态配置需手动在 Prometheus 配置文件中的 scrape_configs 下增加新 job，内容蕴含被监控的 etcd 集群地址，如开启了认证还需配置证书等。

示例：

scrape_configs:
  - job_name: 'etcd'
    static_configs:
      - targets: ['<etcd-node-1>:2379', '<etcd-node-2>:2379', '<etcd-node-3>:2379']
    metrics_path: '/metrics'
    scheme: 'https'
    tls_config:
      ca_file: /path/to/prometheus-server/ca.pem  # 在 Prometheus 服务器上的 CA 证书门路
      cert_file: /path/to/prometheus-server/client.pem  # 客户端证书门路
      key_file: /path/to/prometheus-server/client-key.pem  # 客户端密钥门路

动静配置借助 Prometheus-Operator 的 ServiceMonitor 机制，可主动发现并采集 Kubernetes 集群中的 etcd 服务 metrics。通过创立 ServiceMonitor 资源，Prometheus 可依据 Namespace 和 Labels 主动关联待监控的服务 Endpoint。

示例：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: etcd-service-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: etcd # 依据服务标签抉择匹配的服务
  endpoints:
  - port: http-metrics
    scheme: https
    tlsConfig:
      caFile: /etc/prometheus/secrets/etcd-certs/ca.crt
      certFile: /etc/prometheus/secrets/etcd-certs/client.crt
      keyFile: /etc/prometheus/secrets/etcd-certs/client.key
      insecureSkipVerify: true
  namespaceSelector:
    matchNames:
    - kube-system # 指定监控哪个命名空间下的服务

获取监控数据后，利用 Prometheus 与 Alertmanager 组件设置告警规定至关重要，重点关注影响集群可用性的外围 metric，例如 Leader 状态、切换次数及 WAL 和事务操作延时等。社区提供了一些参考告警规定。

最初，为了晋升运维效率和问题定位能力，能够基于收集到的 metrics，在 Grafana 中创立可视化面板，展现集群 Leader 状态、key 总数、watcher 数、出流量以及 WAL 长久化延时等要害运行状态指标。

在实现监控与告警设置后，确保 etcd 集群在生产环境平安应用还需进行数据备份。针对数据备份，有以下几种办法：

通过指定端口、证书进行手动备份。

etcdCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

应用备份的数据进行复原。

etcdCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  restore save <backup-file-location>

倡议每小时至多备份一次，可通过定时工作实现。

利用 etcd-backup-operator 工具，通过创立备份工作 CRD 实现自动化备份治理，例如配置备份频率、最大保留备份数量以及 S3 存储等参数。

示例：

apiVersion: "etcd.database.coreos.com/v1beta2"
kind: etcdBackup
metadata:
  name: example-etcd-cluster-backup
spec:
  etcdEndpoints: ["http://etcd-cluster-endpoint:2379"] # 替换为你的 etcd 集群理论端点
  storageType: S3
  backupPolicy:
    backupIntervalInSecond: 3600 # 每小时执行一次备份（这里仅为示例，可自定义间隔时间）maxBackups: 5 # 最多保留 5 个备份文件
  s3:
    path: "my-s3-bucket/etcd/backups" # 替换为 S3 存储桶门路
    awsSecret: qy-credentials # 替换为援用 qy 凭据 secret 的名称

最初，为了实现跨地区热备，可在 etcd 集群中增加 Learner 节点。Learner 节点作为非投票成员，不影响集群性能，其原理是追随 Leader 节点同步日志信息。不过请留神，在 etcd 3.4 版本中，仅反对一个 Learner 节点且串行读取。

在 Kubernetes 生态系统中，etcd 作为外围组件起着不可或缺的作用。随着云原生技术的继续演进，etcd 在 Kubernetes 体系中的翻新空间及潜在挑战值得关注。面对将来，etcd 同样须要应答诸多挑战，包含如何高效解决海量数据增长、如何更好地兼容异构基础设施接入，以及如何无效抵挡一直演变的平安危险。但置信在宽广开发者的共同努力下，etcd 将继续冲破，在 Kubernetes 生态系统内推动技术创新，巩固其基石位置。

本文由博客一文多发平台 OpenWrite 公布！

正文完

云计算

发表至：云计算

2024-02-23

0

关于云计算:浪潮云说丨上云迁移实践

关于云计算:Serverless-全能选手再添一金

关于云计算:深度解读智能化编码的技术架构与实践案例

关于云计算:进阶篇丨链路追踪Tracing很简单常见问题排查

关于后端:这才开工没几天收到Offer了简历改的好找工作没烦恼

关于云计算:揭秘KubeSphere-背后的超级大脑etcd-的魅力与力量

1. 开篇：揭开神秘面纱，etcd 如何驱动 KubeSphere 高效运行

2. 时光机：从诞生到崛起，etcd 如何在云原生时代锋芒毕露

3. 深度分析：etcd 外围原理与架构设计，它是如何做到数据存储的十拿九稳

3.1 根底架构图

3.2 etcd 实现高可用、数据一致性的秘诀

3.3 探秘 etcd 读申请：一次闪电般的数据检索之旅

4. 实战演练：构建 KubeSphere 环境下的 etcd 服务

4.1 什么是 KubeSphere？

4.2 架构阐明

4.3 为什么抉择 KubeKey

4.4 环境筹备

4.4.1 获取 KubeKey

4.4.2 装置 Kubernetes+KubeSphere

4.4.3 查看集群状态

4.4.4 装置 etcdctl 工具（可选）

4.4.5 获取证书并查看 etcd 状态

4.6 etcd 部署倡议

4.6.1 零碎要求

4.6.2 集群成员数量尽量为奇数

4.6.3 最大集群大小不超过 7 个

5. etcd 集群运维那些事儿

5.1 监控及告警

5.1.1 动态配置

5.1.2 动静配置

5.2 数据及还原

5.2.1 手动备份复原

5.2.2 定时主动备份

5.2.3 自动化备份

6. 将来可期：瞻望 etcd 在 Kubernetes 生态系统中继续翻新的可能性与挑战

站内搜索