etcd工作原理和部署指南

​ etcd是由CoreOS团队发的一个分布式一致性的KV存储系统，可用于服务注册发现和共享配置，随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用斗老塌到的etcd组件作为一个高可用强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开含档始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。

​ etcd推荐使用奇数作为集群节点个数。因为奇数个节点和其配对的偶数个节点相比，容错能力相同，却可以少一个节点。综合考虑性能和容错能力，etcd官方文档推荐的etcd集群大小是3,5,7。由于etcd使用是Raft算法，每次写入数据需要有2N+1个节点同意可以写入数据，所以部分节点由于网络或者其他不可靠因素延迟收到数据更新，但是最终数据会保持一致，高度可靠。随着节点数目的增加，每次的写入延迟会相应的线性递增，除了节点数量会影响写入数据的延迟，如果节点跟接节点之间的网络延迟，也会导致数据的延迟写入。

结论：

​ 1.节点数并非越多越好，过多的节点将会导致数据延迟写入。

​ 2.节点跟节点之间的跨机房，专线之间网络延迟，也将会导致数据延迟写入。

​ 3.受网络IO和磁盘IO的延迟

​ 4.为了提高吞吐量，etcd通常将多个请求一次批量处理并提交Raft，

​ 5.增加节点，读性能会提升，写性能会下降，减少节点，写性能会提升。

参数说明：

这种方式就是 利用一个已有的 etcd 集群来提供 discovery 服务，从而搭建一个新的 etcd 集群。

假设已有的 etcd 集群的一个访问地址是： myetcd.local ，那么我们首先需要在已有 etcd 中创建一个特殊的 key，方法如下：

其中 value=3 表示本集群的大小，即: 有多少集群节点。而 6c007a14875d53d9bf0ef5a6fc0257c817f0fb83 就是用来做 discovery 的 token。

接下来你在 3 个节点上分别启动 etcd 程序，并加上刚刚的 token。

加 token 的方式同样也有 命令行参数 和 环境变量 两种。

命令行参数:

环境变量

以 命令行参数 启动方式为例：

可以使用etcd附带的 基准 CLI工具完成基准测试etcd性能。

对于一些基准性能数字，我们考虑具有以下硬件配置的三个成员的etcd集群：

有了这个配置，etcd可以大致写出：

示例命令是：

可线性读取请求通过集群成员的法定人数达成一致以获取最新数据。可序列化的读取请求比线性读取要便宜，因为它们由任何单个etcd成员提供，而不是成员法定人数，以换取可能的陈旧数据。etcd可以阅读：

示例命令是：

我们鼓励在新环境中首次安装etcd集群时运行基准测试，以确保集群达到足够的性能群集延迟和吞吐量可能会对较小的环境差异敏感。

以上测试部分翻译空圆自官方文档（ https://coreos.com/etcd/docs/latest/op-guide/performance.html ）

使用外部的 etcd 安装 cilium 在较大的运行环境伏孝中能够提供更好的性能。

当使用外老厅亏部 etcd 作为 cilium 的 k-v 存储，etcd 的 IP 地侍神址需要在 cilium 的 configmap 中配置。

hubble 对前面安装的测试用例监控信息

---