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

1. 开篇：揭开奥秘面纱，etcd 怎么驱动 KubeSphere 高效运转

在云原生年代，etcd 作为 Kubernetes 生态中不可或缺的中心组件，扮演着 KubeSphere 集群“神经体系”的人物。它运用 Raft 共同性算法供给强壮的分布式键值存储才能，保证集群状况信息的实时同步和持久化。

每当在 KubeSphere 中执行资源操作时，这些指令首先经过 etcd 进行处理和分发，然后完结对整个集群状况的瞬时更新与办理。正是由于 etcd 的存在，KubeSphere 才得以在大规模容器编排中展现杰出的功能和稳定性。

接下来，咱们将深入探究 etcd 怎么巧妙地融入 KubeSphere 生态体系，并经过实践运用场景展现其对提高渠道工作功率和可靠性的要害作用。

2. 时光机：从诞生到兴起，etcd 怎么在云原生年代锋芒毕露

etcd 的旅程始于 2013 年 CoreOS 团队的一项立异测验，跟着其 V1 和 V2 版别的开展，逐渐奠定了在分布式体系数据共同性处理方案中的方位。从 etcd V1、V2 到 V3 版别的迭代进程中，功能不断提高，稳定性日益增强，功能上也不断丰富和完善。

经历数次重要晋级后，etcd V3 版别特别显著地处理了 Kubernetes 开展进程中面临的存储瓶颈问题。在功能方面，经过优化完结了更快的数据读写速度；在稳定性上，引入了更为健壮的共同性保证机制；在功能上，则扩展了 API 接口，增强了安全性与可办理性。

因此，etcd 凭仗这些改善，在功能、稳定性和功能上的杰出表现成功捍卫了作为 Kubernetes 中心存储组件的方位，并在云原生年代中扮演着不可或缺的人物，继续推动整个生态体系的进步与开展。

3. 深度剖析：etcd 中心原理与架构规划，它是怎么做到数据存储的满有把握

3.1 基础架构图

etcd 是典型的读多写少存储，实践业务场景中，读一般占有 2/3 以上的恳求。为了让我们对 etcd 每个模块有必定的开始了解，简略介绍一下每个模块的功能作用。

揭秘！KubeSphere 背面的“超级大脑”：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 则担任实践的数据存储与检索。

3.2 etcd 完结高可用、数据共同性的诀窍

诀窍就是 Raft 算法，旨在简化分布式体系中的一致问题了解与完结。它将杂乱的一致进程分解为三个要害环节：

  • Leader 推举：保证在 Leader 节点失效时能快速重新推举出新的 Leader。

  • 日志仿制：经过仅允许 Leader 节点写入日志，并担任向 Follower 节点仿制日志记录，以保证集群内部数据共同性。

  • 安全性：在安全性方面，Raft 算法规划了严厉的规矩，例如一个任期内仅产生一个有用的 Leader、先前已提交的日志条目在新 Leader 上必定存在，且一切节点的状况机运用的相同方位应具有相同的日志内容。这一系列机制共同保证了分布式体系的稳定性和共同性。

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

在分布式体系背景下，看似简略的数据读取操作实则蕴含杂乱机制。关于 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 默许且理想的读取方式。

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

4.1 什么是 KubeSphere？

KubeSphere是在 Kubernetes之上构建的面向云原生运用的分布式操作体系，彻底开源，支撑多云与多集群办理，供给全栈的 IT 自动化运维才能，简化企业的 DevOps 工作流。它的架构可以十分方便地使第三方运用与云原生生态组件进行即插即用 (plug-and-play) 的集成。

4.2 架构阐明

KubeSphere 将前端与后端分开，完结了面向云原生的规划，后端的各个功能组件可经过 REST API 对接外部体系。可参阅 API 文档。下图是体系架构图。KubeSphere 无底层的基础设施依靠，可以运转在任何 Kubernetes、私有云、公有云、VM 或物理环境（BM）之上。此外，它可以布置在任何 Kubernetes 发行版上。

揭秘！KubeSphere 背面的“超级大脑”：etcd 的魅力与力气

4.3 为什么挑选 KubeKey

KubeKey 由 Go 言语开发，运用快捷、轻量，支撑多种干流 Linux 发行版。KubeKey 支撑多种集群布置形式，例如 All-in-One、多节点、高可用以及离线集群布置。KubeKey 也支撑快速构建离线装置包，加快离线交付场景下的集群交付功率。KubeKey 完结多节点并行装置，且运用 Kubeadm 对集群和节点进行初始化，极大地节省了集群布置时刻，一起也遵循了 Kubernetes 社区干流集群布置方法。KubeKey 供给内置高可用形式，支撑一键布置高可用 Kubernetes 集群。

4.4 环境预备

为了演示作用运用 all-in-one 快速布置。

4.4.1 获取 KubeKey

export KKZONE=cn

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

chmod  x kk

4.4.2 装置 Kubernetes KubeSphere

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

揭秘！KubeSphere 背面的“超级大脑”：etcd 的魅力与力气

4.4.3 检查集群状况

揭秘！KubeSphere 背面的“超级大脑”：etcd 的魅力与力气

4.4.4 装置 etcdctl 东西（可选）

运用 KubeKey 布置集群会默许装置 etcdctl。

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

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

cp etcdctl /usr/local/bin/

4.4.5 获取证书并查看 etcd 状况

阐明：KubeKey 装置集群时默许 etcd 运用二进制装置，证书途径默许在此处。

/etc/ssl/etcd/ssl

揭秘！KubeSphere 背面的“超级大脑”：etcd 的魅力与力气

经过选用 KubeKey 东西施行最小化布置案例，展现了怎么运用安全证书机制来完结对 etcd 的拜访以监控集 etcd 服务状况。虽然此处演示以单一实例呈现，但在实践出产环境中，etcd 服务必定是依据高可用集群形式运转，始终坚守着高可靠性的中心准则。

4.6 etcd 布置主张

4.6.1 体系要求

为保证 etcd 功能，引荐运用 SSD 硬盘，并经过东西（如 fio）进行磁盘速度评价。主张体系装备至少与默许存储配额（2GB）相等的 RAM，一般引荐 8GB 以上以避免功能下降。典型布置中，etcd 集群应在具有双核 CPU、2GB 内存和 80GB SSD 的专用服务器上运转。请依据实践工作负载对硬件装备进行调整并预先测验，保证出产环境功能达标。

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

etcd 集群达成状况更新一致需求多数节点参加，即至少（n/2） 1 个成员在具有 n 个节点的集群中。关于奇数节点数量的集群，增加一个节点虽表面上增强了体系规模，但实践上降低了容错性：相同数量节点毛病时仍能保持裁定，但更多节点毛病或许导致裁定丢掉。因此，在集群无法忍受额定毛病且新节点或许注册失利的情况下，贸然增加节点是危险的，由于这或许导致永久性的裁定损失。

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

理论上，etcd 集群规模无清晰上限，但实践中引荐不超越 7 个节点。参照 Google 内部广泛布置的 Chubby 锁服务经历，主张保持 5 节点装备。这样的集群能忍受两个成员毛病，一般已满意需求。虽然更大集群提高容错性，但会因数据在更多节点上的仿制而导致写入功能下降。

5. etcd 集群运维那些事儿

5.1 监控及告警

在构建和运维 etcd 集群时，监控是保证业务稳定性和提早辨认危险的要害步骤。

etcd 供给了众多 metrics，按模块区分包括磁盘、网络、MVCC 事务、gRPC RPC 和 etcdserver 等中心目标，用于展现集群健康状况。为了有用监控这些目标，引荐运用 Prometheus 服务采集 etcd 2379 端口的 metrics 数据，并可经过静态或动态装备完结。

5.1.1 静态装备

静态装备需手动在 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  # 客户端密钥途径

5.1.2 动态装备

动态装备借助 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 # 指定监控哪个命名空间下的服务

揭秘！KubeSphere 背面的“超级大脑”：etcd 的魅力与力气

获取监控数据后，运用 Prometheus 与 Alertmanager 组件设置告警规矩至关重要，要点重视影响集群可用性的中心 metric，例如 Leader 状况、切换次数及 WAL 和事务操作延时等。社区供给了一些参阅告警规矩。

最终，为了提高运维功率和问题定位才能，可以依据收集到的 metrics，在 Grafana 中创立可视化面板，展现集群 Leader 状况、key 总数、watcher 数、出流量以及 WAL 持久化延时等要害运转状况目标。

揭秘！KubeSphere 背面的“超级大脑”：etcd 的魅力与力气

5.2 数据及还原

在完结监控与告警设置后，保证 etcd 集群在出产环境安全运用还需进行数据备份。针对数据备份，有以下几种方法：

5.2.1 手动备份康复

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

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>

5.2.2 守时自动备份

主张每小时至少备份一次，可经过守时使命完结。

5.2.3 自动化备份

运用 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 节点且串行读取。

6. 未来可期：展望 etcd 在 Kubernetes 生态体系中继续立异的或许性与应战

在 Kubernetes 生态体系中，etcd 作为中心组件起着不可或缺的作用。跟着云原生技术的继续演进，etcd 在 Kubernetes 体系中的立异空间及潜在应战值得重视。面临未来，etcd 同样需求应对诸多应战，包括怎么高效处理海量数据增加、怎么更好地兼容异构基础设施接入，以及怎么有用抵御不断演化的安全危险。但相信在广大开发者的共同努力下，etcd 将继续打破，在 Kubernetes 生态体系内推动技术立异，安定其基石方位。

本文由博客一文多发渠道 OpenWrite 发布！