本文所有命令均在 etcdctl 默认api ，即 etcd api v2 下 *** 作，v3 指令略有改动可能不匹配，详情请查阅官方文档： https://etcd.io/docs/
查看版本
查看 Etcd 暴露出来的 prometheus 指标，在 prometheus 对其监控时可调用
查看 etcd、etcd api v2 版本
查看 etcd、etcd api v3 版本
查询节点 ID
删除节点，如删除 Eecd3
修改配置文件 etcd.conf，修改参数 ETCD_INITIAL_CLUSTER 并移除节点信息，重启etcd服务
1）在群集中删除故障节点
在任意一 etcd 节点服务器查询该节点 ID，通过ID删除故障节点， *** 作步骤如下
删除目标节点的数据
2）编辑目标节点配置文件，将 --initial-cluster-state值改为 existing （否则会生成新的ID，与原ID不匹配将无法加入集群）
3）加入节点至集群，需输入目标节点的 etcd name 和 PEER_URLS
4）启动目标节点 etcd 服务
5）查看集群健康状态
停止 Etcd 服务
备份并删除当前 Etcd 数据
注意：此方法恢复数据可能不完整，仅建议极端环境下使用，常规数据恢复请使用快照
https://blog.csdn.net/ccy19910925/category_7590496.html
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 ）
准备3台机器，分别设置hostname如下所示（此处主要是为了便于标识不同的机器，其实不设置hostname也可以正常搭建）：
参考《 使用Kubeadm搭建Kubernetes(1.13.1)集群 》在 master1 搭建一个单master节点的k8s集群。
参考《 使用Kubeadm搭建Kubernetes(1.13.1)集群 》在 master2 和 master3 安装 docker、kubeadm 、 kubectl、flannel ，但不要执行 kubeadm init 。（如果执行了 kubeadm init 也没关系，再执行 kubeadm reset 就行了）。
然后在 master1 节点 /etc/kubernetes/ 目录下执行 tar -czvf pki.tar.gz pki 对 pki 目录进行压缩生成 pki.tar.gz 文件。
将pki.tar.gz文件上传到第二和第三个master节点{$HOME}/~目录下（可以用scp、rsync、sz/rz等命令都可以）。
然后在第二和第三个master节点{$HOME}/~目录下执行如下命令将证书拷贝到 /etc/kubernetes/pki/ 目录下：
注意：一定要删除etcd相关的证书，否则会把整个k8s集群搞挂。
在第一步master1搭建完成后，会得到如下的 kubeadm join 命令。这一步在master2和master3分别执行该 kubeadm join 命令即可。
注意：一定要加上参数 --experimental-control-plane
登录master1，修改 /etc/kubernetes/manifests/etcd.yaml 。这一步的目的是启动只有一个etcd节点的集群，然后往这个集群中添加新节点等待数据同步。
然后重启kubelet
通过 sudo docker ps 查看启动的etcd容器ID
通过 sudo docker exec -it b69913e36ce1 sh 进入容器内。
通过下面的命令可以查看当前etcd集群的节点列表：
可以看到当前集群中只有一个节点：
此时，apiserver已经可以正常访问etcd，可以通过 kubectl get nodes 验证一下：
如果不小心在master节点上执行了 sudo kubeadm reset -f ,导致节点重置，etcd容器被kill，数据清空。直接通过 kubeadm join xxx 并不能直接将该节点添加回去，而会报出下面的错误：
解决方案参考文档： Kubernetes master无法加入etcd 集群解决方法
解决方法：
1.在kubeadm-config删除的状态不存在的etcd节点：
把上边的删掉：
我尝试了方案一，然后重新执行下面的命令，问题就成功解决了。
效果如下：
在执行kubectl join xxx命令时，出现这种情况是和docker残留信息有关系，可以考虑重启docker：
这样反复多试几次就成功了（个人经验）。
出现这种情况的原因是：该master节点安装flannel失败了。
此时，如果查看kubelet的状态，一般是启动失败的状态。通过 sudo journalctl xe - no-pager 可以看到如下报错误信息：
这种情况可以尝试手动安装flannel，然后重启机器就可以解决，flannel安装过程参考《 安装Kubernetes报错：STATUS NotReady 》
如果上述方式不管用，可以尝试下面的方式：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）