操作指南 on PIG.CENTER

配置选项

Mon, 01 Jan 0001 00:00:00 +0000

可以通过以下方式配置 etcd：

命令行标志
环境变量：每个标志都有一个对应的环境变量，其名称与标志相同，但前缀为 ETCD_，并以全大写和 [蛇形命名法][] 格式化。例如，--some-flag 对应 ETCD_SOME_FLAG。
配置文件

警告

请注意：如果混合使用配置选项，则以下规则适用。

传输安全模型

Mon, 01 Jan 0001 00:00:00 +0000

etcd 支持自动 TLS，以及通过客户端证书实现的客户端到服务器和对等成员（服务器到服务器 / 集群）通信的身份认证。请注意，etcd 默认不启用基于 RBAC 的身份认证或传输层的身份认证功能，以降低用户入门时的使用门槛。此外，更改此默认设置将对该项目造成破坏性变更，该项目自 2013 年确立以来一直保持该设定。未启用安全功能的 etcd 集群可能使数据暴露于任意客户端。

集群指南

Mon, 01 Jan 0001 00:00:00 +0000

概述

静态启动 etcd 集群要求每个成员均知晓集群中的其他成员。在某些情况下，集群成员的 IP 地址可能无法提前确定。在这些情况下，可以借助发现服务来引导启动 etcd 集群。

以 Kubernetes StatefulSet 运行 etcd 集群

Mon, 01 Jan 0001 00:00:00 +0000

以下演示如何作为 Kubernetes StatefulSet 执行静态引导过程。

示例 Manifest

本文档包含用于在 Kubernetes 中部署静态 etcd 集群的服务和有状态集（StatefulSet）配置。

在容器中运行 etcd 集群

Mon, 01 Jan 0001 00:00:00 +0000

本文指南展示了如何使用 Docker 以静态引导过程运行 etcd。

Docker

为使 Docker 主机外部的客户端能够访问 etcd API，请使用容器的主机 IP 地址。有关获取 IP 地址的详细信息，请参见 docker inspect 。或者，可向 docker run 命令指定 --net=host 标志，以跳过将容器置于独立网络栈中的操作。

故障模式

Mon, 01 Jan 0001 00:00:00 +0000

在大规模机器部署中，故障是常见现象。当硬件或软件发生故障时，机器会失效。若出现断电或网络问题，多台机器可能同时失效。多种类型的故障也可能同时发生；几乎无法穷举所有可能的故障场景。

灾难恢复

Mon, 01 Jan 0001 00:00:00 +0000

etcd 设计用于抵御机器故障。etcd 集群可自动从临时故障（例如机器重启）中恢复，并能容忍最多 (N−1)/2 个成员的永久性故障，适用于由 N 个成员组成的集群。当某个成员发生永久性故障（无论是硬件故障还是磁盘损坏）时，该成员将失去对集群的访问权限。若集群永久性丢失超过 (N−1)/2 个成员，则将发生灾难性故障，法定人数不可逆地丢失。一旦法定人数丢失，集群将无法达成共识，因而无法继续接受更新。

etcd 网关

Mon, 01 Jan 0001 00:00:00 +0000

etcd 网关是什么

etcd 网关是一个简单的 TCP 代理，负责将网络数据转发至 etcd 集群。网关为无状态且透明的；它既不检查客户端请求，也不干扰集群响应。网关不会终止 TLS 连接，不会代表客户端执行 TLS 握手，也不会验证连接是否已加密。

gRPC 代理

Mon, 01 Jan 0001 00:00:00 +0000

gRPC 代理是运行在 gRPC 层（L7）的无状态 etcd 反向代理。该代理旨在降低核心 etcd 集群的总体处理负载。为实现横向扩展，代理会合并监听和租约 API 请求。为防止恶意客户端对集群造成影响，代理会缓存键范围请求。

硬件推荐

Mon, 01 Jan 0001 00:00:00 +0000

etcd 在资源有限的开发或测试环境中通常运行良好；在笔记本电脑或廉价云主机上开发 etcd 是常见做法。然而，在生产环境中运行 etcd 集群时，遵循一些硬件建议有助于实现有效的系统管理。这些建议并非硬性规定，而是构建稳健生产部署的良好起点。和往常一样，部署前应使用模拟工作负载进行测试。

维护

Mon, 01 Jan 0001 00:00:00 +0000

概述

etcd 集群需要定期维护以保持可靠性。根据 etcd 应用的需求，此类维护通常可以自动化执行，且无需停机或显著降低性能。

监控 etcd

Mon, 01 Jan 0001 00:00:00 +0000

每个 etcd 服务器通过其客户端端口上的 HTTP 端点提供本地监控信息。监控数据对于系统健康检查和集群调试均具有实用价值。

调试端点

若设置 --log-level=debug，etcd 服务器将在其客户端端口的 /debug 路径下导出调试信息。设置 --log-level=debug 时需谨慎，因为会导致性能下降和日志输出过于 verbose。

性能

Mon, 01 Jan 0001 00:00:00 +0000

理解性能

etcd 提供稳定、持续的高性能。性能由两个因素决定：延迟和吞吐量。延迟是指完成操作所需的时间。吞吐量是指在一定时间周期内完成的总操作数。通常情况下，当 etcd 接受并发客户端请求时，平均延迟会随着整体吞吐量的增加而上升。在常见的云环境（如 Google Compute Engine (GCE) 上的标准 n-4 实例，或 AWS 上相当的机器类型）中，三成员 etcd 集群在轻负载下请求完成时间小于 1 毫秒，重负载下每秒可完成超过 30,000 次请求。

运行时重配置设计

Mon, 01 Jan 0001 00:00:00 +0000

运行时重配置是分布式系统中最为复杂且最容易出错的功能之一，尤其是在基于共识的系统（如 etcd）中。

继续阅读以了解 etcd 运行时重配置命令的设计原理，以及我们如何解决这些问题。

运行时重配置

Mon, 01 Jan 0001 00:00:00 +0000

etcd 支持增量式运行时重配置，允许用户在运行时更新集群成员。

重新配置请求仅在集群多数成员正常运行时才能处理。生产环境中强烈建议始终将集群规模设置为大于二。从两成员集群中移除成员是不安全的。两成员集群的多数为两个。若在移除过程中发生故障，集群可能无法继续推进，需从多数故障中重启。

支持的平台

Mon, 01 Jan 0001 00:00:00 +0000

支持层级

etcd 可在不同平台上运行，但其提供的保证取决于平台的支持级别：

Tier 1：由 [etcd 维护者][] 完全支持；etcd 保证通过所有测试，包括功能测试和健壮性测试。
Tier 2：etcd 保证通过集成测试和端到端测试，但不保证通过功能测试或健壮性测试。
Tier 3：etcd 保证可构建，可能仅进行轻度测试（或未测试），因此应视为 不稳定。

当前支持

下表列出了当前支持的平台及其对应的 etcd 支持级别：

版本管理

Mon, 01 Jan 0001 00:00:00 +0000

本文描述了 etcd 项目所支持的版本。

服务版本管理与支持版本

etcd 版本号采用 x.y.z 格式，其中 x 表示主版本号，y 表示次版本号，z 表示补丁版本号，遵循语义化版本控制规范。新次版本号可能向 API 添加额外功能。

数据损坏

Mon, 01 Jan 0001 00:00:00 +0000

etcd 内置了自动数据损坏检测机制，以防止成员状态发生不一致。

启用数据损坏检测

数据损坏检测可通过以下方式执行：

初始检查，通过 --experimental-initial-corrupt-check 标志启用。
定期检查包括：
- 已压缩的修订版本哈希，通过 --experimental-compact-hash-check-enabled 标志启用。
- 最新修订版本哈希，通过 --experimental-corrupt-check-time 标志启用。

引导过程中将执行初始检查。成员将比较其持久化状态与其他成员的状态，若发现不匹配则退出。