前言：
etcd集群作为kubernetes集群的大脑，重要性不言而喻，但我好像没有对etcd集群做过一个全方面的总结，部署手法也只是单调的使用ansible快速部署，很多细节并没有说清楚，并且对于etcd集群部署后的性能调优也没有过多的提及。因此，本文将对etcd集群的由来，etcd集群的特点，etcd集群的部署手法，etcd应该注意的调优方案这些做一个全面的总结。
一，etcd集群的由来，特点，地位
etcd集群的由来：
名称 “etcd” 源自两个想法，即 unix “/etc” 文件夹 和 “d” 分布式系统。“/etc” 文件夹是用于存储单个系统的配置数据的位置，而 etcd 用于存储大规模分布式的配置信息。因此，分配了 “d” 的 “/etc” 就是 “etcd”。
etcd 被设计为大型分布式系统的通用基板。这些大型系统需要避免脑裂问题，并且愿意牺牲可用性来实现此目的。 etcd 以一致且容错的方式存储元数据。 etcd 集群旨在提供具有稳定性、可靠性、可伸缩性和性能的键值存储，也因此etcd通常也可以被称之为非关系型键值对数据库
分布式系统将 etcd 用作配置管理、服务发现和协调分布式工作的一致键值存储组件。许多组织在生产系统上使用 etcd，例如容器调度程序、服务发现服务和分布式数据存储。使用 etcd 的常见分布式模式包括领导者选举、分布式锁和监视机器活动状态等。
etcd集群在kubernetes集群内的地位：
etcd是 Kubernetes的关键组件，因为它存储了集群的整个状态：集群的配置，规格以及运行中的工作负载的状态。在Kubernetes世界中，etcd用作服务发现的后端，并存储集群的状态及其配置。
由于etcd如此的重要，因此，通常Etcd被部署为一个集群，几个节点的通信由Raft算法处理。在生产环境中，集群包含奇数个节点，并且至少需要三个。（多啰嗦几句，集群可以保证服务的高可用，当然，kubernetes集群可以只使用一个单实例的etcd，但，这么重要的组件如果某天突然坏了，是那种无法恢复的损坏，kubernetes集群是不是就彻底报废了？为了避免这么尴尬的情况出现，我们需要一个分布式集群来降低集群挂掉的概率，当然，集群的好处之一是一个节点彻底无法恢复了可以快速的扩展集群，克隆复制出一个新节点从而顶替损坏的节点。）
etcd集群的基本特点：
- 简单性：使用标准HTTP工具（如curl）读取和写入值，其实呢，也就是我们常说的对外接口
- 观测性：可持续watch key的变化，做出相应的响应，
- 高可用：分布式集群，解决单点故障
- 完全复制：每个节点都是一份完整的的存档
- 安全：带有客户端验证的TLS
- 一致性：每次读取都会返回垮多主机的最新写入，这里的一致性主要指的是数据的强一致性。
为什么kubernetes选择的是etcd而不是zookeeper？
ZooKeeper 是一款与 etcd 十分类似的键值对存储数据库，都是分布式系统协调和元数据存储。但是， etcd 踩在前人的肩膀上，其参考了 ZooKeeper 的设计和实现经验。从 Zookeeper 汲取的经验教训无疑为 etcd 的设计提供了支撑，从而帮助其支持 Kubernetes 等大型系统。对 Zookeeper 进行的 etcd 改进包括：
- 动态重新配置集群成员
- 高负载下稳定的读写
- 多版本并发控制数据模型
- 可靠的键值监控
- 用于分布式共享锁的 API
etcd是go语言编写的，天然契合kubernetes集群（亲儿子嘛），并且etcd 开箱即用地支持多种语言和框架。Zookeeper 拥有自己的自定义Jute RPC 协议，该协议对于 Zookeeper 而言是完全唯一的，并限制了其受支持的语言绑定，而 etcd 的客户端协议则是基于 gRPC 构建的，gRP 是一种流行的 RPC 框架，具有 go，C ++，Java 等语言支持。同样，gRPC 可以通过 HTTP 序列化为 JSON，因此即使是通用命令行实用程序（例如curl）也可以与之通信。由于系统可以从多种选择中进行选择，因此它们是基于具有本机工具的 etcd 构建的，而不是基于一组固定的技术围绕 etcd 构建的。
在综合考虑功能，支持和稳定性时，etcd 相比于 Zookeeper，更加适合用作一致性的键值存储的组件。总结一句话，etcd的功能和性能以及对其它语言的支持友好度方面etcd是有明显优势的。
etcd集群节点数量的相关说明：
etcd 是基于 raft算法的分布式键值数据库，生来就为集群化而设计的，由于Raft算法在做决策时需要超半数节点的投票，所以etcd集群一般推荐奇数节点，如3、5或者7个节点构成一个集群。
etcd官方推荐3、5、7个节点，虽然raft算法也是半数以上投票才能有 leader，但奇数只是推荐，其实偶数也是可以的。如 2、4、8个节点。下面分情况说明：
- 1 个节点：就是单实例，没有集群概念，不做讨论
- 2 个节点：是集群，但没人会这么配，这里说点废话：双节点的etcd能启动，启动时也能有主，可以正常提供服务，但是一台挂掉之后，就选不出主了，因为他只能拿到1票，剩下的那台也无法提供服务，也就是双节点无容错能力，不要使用。
- 3 节点：标准的3 节点etcd 集群只能容忍1台机器宕机，挂掉 1 台此时等于2个节点的情况，如果再挂 1 台，就和 2节点的情形一致了，一直选，一直增加任期，但就是选不出来，服务也就不可用了
- 4 节点：最大容忍1 台 服务器宕机
- 5 节点：最大容忍 2 台 服务器宕机
- 6 节点：最大容忍 2 台 服务器宕机
- 7和8个节点，最大容忍3台 服务器宕机
以此类推，9和10个节点，最大容忍4台 服务器宕机，总结以上可以得出结论：偶数节点虽然多了一台机器，但是容错能力是一样的，也就是说，你可以设置偶数节点，但没增加什么能力，还浪费了一台机器。同时etcd 是通过复制数据给所有节点来达到一致性，因此偶数的多一台机器增加不了性能，反而会拉低写入速度。
etcd集群节点数越多越好吗？
那可能有同学会说，我搞个几十上百台服务器做etcd集群，那集群的整体性能不是屌炸了，etcd集群永不会停止嘛。有这个想法那就大错特错了，etcd 集群是一个 Raft Group，没有 shared。所以它的极限有两部分，一是单机的容量限制，内存和磁盘；二是网络开销，每次 Raft 操作需要所有节点参与，每一次写操作需要集群中大多数节点将日志落盘成功后，Leader 节点才能修改内部状态机，并将结果返回给客户端。因此节点越多性能越低，并且出错的概率会直线上升，并且是呈现线性的性能下降，所以扩展很多 etcd 节点是没有意义的，其次，如果etcd集群超过7个达到十几个几十个，那么，对运维来说也是一个不小的压力了，并且集群的配置什么的也会更加的复杂，而不是简单易用了。因此，etcd集群的数量一般是 3、5、7， 3 个是最低标准，7个也就是最高了。
二，kubernetes集群和etcd集群的结合方式：
由于kubernetes官方是强烈推荐etcd作为集群的服务状态存储管理工具的，因此，kubernetes和etcd是可以深度绑定融合的，etcd实例可以作为Pod部署在master节点上，也就是常说的etcd堆叠式集群。还一种是kubernetes和etcd为了增加安全性和弹性，而采用解耦形式的扩展etcd集群，也就是kubernetes集群使用外部的etcd集群。通常的两者结合方式就这么两种。它们的通常的架构图如下：
堆叠式etcd集群架构图
扩展式etcd集群架构图
部署方式：
etcd堆叠式集群通常指的是kubeadm方式部署的多masterkubernetes集群，如上图所示，多套kubernetes组件组成kubernetes集群，其中就包含了etcd。
扩展式外部集群通常指的是独立于kubernetes集群部署的二进制方式部署的etcd集群。而二进制方式部署又可以使用自动化的工具ansible部署或者手工搭建etcd集群。那么，下面就来一次手工搭建etcd集群吧。
二进制手工搭建etcd集群：
etcd集群用三台centos7搭建完成。
etcd-1：192.168.217.19
etcd-2：192.168.217.20
etcd-3：192.168.217.21
一、创建CA证书和密钥，下面步骤是在k8s-master1上操作的。
1、所有机器上创建相关目录
mkdir -p /opt/etcd/{bin,ssl,cfg} echo 'export PATH=$PATH:/opt/etcd/bin' >> /etc/profile source /etc/profile
2、下载cfssl
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfssl curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o /usr/local/bin/cfssl-certinfo chmod +x /usr/local/bin/cfssl /usr/local/bin/cfssljson /usr/local/bin/cfssl-certinfo
3、创建证书签发机构CA，先创建一个证书制作的文件夹。
mkdir -p /data/ssl cd /data/ssl cat > ca-config.json <<EOF { "signing": { "default": { "expiry": "87600h" }, "profiles": { "kubernetes": { "usages": [ "signing", "key encipherment", "server auth", "client auth" ], "expiry": "87600h" } } } } EOF ca-config.json：可以定义多个 profiles，分别指定不同的过期时间、使用场景等参数；后续在签名证书时使用某个 profile； signing：表示该证书可用于签名其它证书；生成的 ca.pem 证书中 CA=TRUE； server auth：表示 client 可以用该 CA 对 server 提供的证书进行验证； client auth：表示 server 可以用该 CA 对 client 提供的证书进行验证；
4、创建CA证书签名请求
cat > ca-csr.json <<EOF { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "L": "beijing", "ST": "beijing", "O": "k8s", "OU": "System" } ] } EOF CN：Common Name，kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name)，浏览器使用该字段验证网站是否合法； O：Organization，kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group)； kube-apiserver 将提取的 User、Group 作为 RBAC 授权的用户标识；
6、生成 CA 证书和私钥：
cfssl gencert -initca ca-csr.json | cfssljson -bare ca - [root@master1 ssl]# ls ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem 拷贝etcd证书到相关文件夹 cp *.pem /opt/etcd/ssl/
7、创建 etcd 证书签名请求，在存放etcd证书的文件夹内制作
cd /opt/etcd/ssl/ cat > etcd-csr.json <<EOF { "CN": "etcd", "hosts": [ "192.168.217.19", "192.168.217.20", "192.168.217.21" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "L": "beijing", "ST": "wuhan", "O": "k8s", "OU": "System" } ] } EOF
8、生成etcd证书和对应的私钥
cfssl gencert -ca=/opt/etcd/ssl/ca.pem \ -ca-key=/opt/etcd/ssl/ca-key.pem \ -config=/opt/etcd/ssl/ca-config.json \ -profile=kubernetes etcd-csr.json \ | cfssljson -bare etcd cp *.pem /opt/etcd/ssl/
注意：证书3个etcd都要放哦。
ETCD使用证书的组件如下：
etcd：使用 ca.pem、etcd-key.pem、etcd.pem；
