etcd运维操作

ByteObsidianVoyantPro
• 阅读 5727

由于etcd需要TLS认证，在master节点上有访问etcd需要的证书，所以最好在master节点上进行操作。
Etcd各节点地址和证书路径信息可以查看kube-apiserver的启动参数：ps -ef|grep kube-apiserver 启动参数中都会有etcd的节点地址和证书路径信息
Etcdctl命令依赖以下环境变量，操作前需先进行环境变量设置（需根据实际环境进行修改）

export ENDPOINTS=https://192.168.0.1:2379,https://192.168.0.2:2379,https://192.168.0.3:2379
export CA_FILE=/etc/kubernetes/ssl/ca.pem
export CERT_FILE=/etc/etcd/ssl/etcd.pem
export KEY_FILE=/etc/etcd/ssl/etcd-key.pem

基本操作

列出节点成员

V2:
export ETCDCTL_API=2
etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE member list
V3:
export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member list

查看节点的健康状态

V2:
export ETCDCTL_API=2
etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE cluster-health
V3:
export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE endpoint health

查看节点的状态

V2:
无此命令
V3:
export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE endpoint status -w table

查看flannel配置信息

V2:
# export ETCDCTL_API=2
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls
/kubernetes
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls /kubernetes
/kubernetes/network
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls /kubernetes/network
/kubernetes/network/config
/kubernetes/network/subnets
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE get /kubernetes/network/config
{"Network":"172.1.0.0/16", "Subnetlen":24, "Backend": {"Type":"vxlan"}}
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls /kubernetes/network/subnets
/kubernetes/network/subnets/172.1.80.0-24
/kubernetes/network/subnets/172.1.44.0-24
/kubernetes/network/subnets/172.1.66.0-24
/kubernetes/network/subnets/172.1.89.0-24
/kubernetes/network/subnets/172.1.18.0-24
/kubernetes/network/subnets/172.1.42.0-24
/kubernetes/network/subnets/172.1.5.0-24
/kubernetes/network/subnets/172.1.68.0-24
/kubernetes/network/subnets/172.1.71.0-24
/kubernetes/network/subnets/172.1.57.0-24
/kubernetes/network/subnets/172.1.59.0-24
/kubernetes/network/subnets/172.1.9.0-24
/kubernetes/network/subnets/172.1.101.0-24
/kubernetes/network/subnets/172.1.29.0-24
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE get /kubernetes/network/subnets/172.1.29.0-24
{"PublicIP":"x.x.x.x","BackendType":"vxlan","BackendData":{"VtepMAC":"96:76:bc:31:b0:00"}}

通过以上步骤，可以查看到flannel的配置子网和后端的配置信息，还能看到各节点flannel.1接口对应的mac和信息和节点IP信息

flannel在etcd中保存信息的路径也可以在flannel的配置文件中查看到，可通过cat /etc/flanneld/flanneld或ps -ef|grep flannel查看到

查看k8s集群API资源信息

export ETCDCTL_API=3
#获取所有的key值
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE get / --prefix --keys-only
#查看pod信息
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE get /registry/pods --prefix --keys-only
#查看service信息
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE get /registry/services/specs --prefix --keys-only
#以上路径可根据需要进行修改

查看集群告警信息

export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE alarm list

数据备份

备份一个节点的数据就可以恢复，实践中，为了防止定时任务配置的节点异常没有生成备份，建议多在几个节点配置定时备份。备份示例脚本如下

export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE snapshot save cluster1_1198_366_49k.db

集群恢复

Etcd能够承受节点的短期失效。当有节点短期失效时，集群能够自动恢复。当集群的节点数为N时，能够承受最大（N-1）/2的节点失效后自动恢复；若失效的节点数超过（N-1）/2，将会由于无法使得半数以上节点达成共识而造成整个集群失效
为了恢复失效的集群，etcd提供了快照功能和恢复措施用于重建整个集群而不会导致丢失数据

获取快照数据

恢复一个集群首先需要从一个集群节点获取快照数据。快照可以是通过etcdctl snapshot save从一个存活的节点进行备份或者直接从节点的etcd数据目录复制member/snap/db文件。下面的命令是从一个存活的节点备份快照数据

ETCDCTL_API=3 etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE snapshot save snapshot.db

恢复集群

恢复集群只需要一个快照db文件即可。使用etcdctl snapshot restore命令恢复集群时，集群会创建新的数据目录，并且所有的member都必须使用同一个db文件进行恢复
恢复集群时，可选择性地对db文件的完整性进行校验。如果db文件是通过etcdctl snapshot save命令保存得到的，则db文件中会包含一个db文件完整性校验的hash值，这个值可用于etcdctl snapshot restore该db文件时进行校验；如果db文件是从节点的数据目录直接复制过来的，则db文件不会包含这个hash值，在执行etcdctl snapshot restore指令时，需要加上--skip-hash-check选项
etcdctl snapshot restore操作会初始化新的节点数据目录，并且使用新的配置信息，但是会保留快照中的原始key数据和值信息。如下示例命令恢复一个节点，恢复的数据目录在/var/lib/etcd/infra4，目标集群各个节点需要分别执行恢复命令

$ etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra4 
--data-dir=/var/lib/etcd/infra4 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23804

接下来使用恢复得到的数据目录启动各个节点，以下示例命令恢复一个节点，同理，目标集群的各个节点需要分别执行脚本进行启动

#!/bin/bash
node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra4
etcd 
--name=infra4 
--initial-advertise-peer-urls=https://$node4:23804 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node4:23804 
--listen-client-urls=https://$node4:23794 
--advertise-client-urls=https://$node4:23794 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806

Etcd配置变更

Etcd集群配置变更需要在集群大多数节点功能正常的情况下进行，并且强烈建议集群的数量必须大于2，如果从一个节点数为2的集群中删除一个节点时，将导致集群不可用

配置变更使用场景

  • 主机按照计划进行维护，如硬件升级
  • 变更集群大小
  • 更换一个出现故障的member
  • 集群多数节点异常，需要重启集群

配置变更相关的操作

配置变更需要在集群大多数（1/2以上）节点工作正常的情况下进行，这是任何一种配置变更的先决条件。
对集群做任何一种变更都必须按顺序操作，不能乱序，例如：

  • 要更新一个节点的peerURLs，只执行一次更新操作
  • 要替换一个健康的节点成员，则先删除旧的成员，再添加新的成员，而不能直接替换
  • 要将集群的节点数从3扩大至5，则需要执行两次增加节点的操作，而不能一次增加两个节点
  • 要将集群的节点数从5降至3，则需要执行两次删除节点的操作，而不能一次删除两个节点

更新一个节点

更新节点advertise client URLs

要更新某个节点的advertise client URLs，只需要在该节点的配置中更新advertise client URLs，然后重启该节点的etcd，重启后，该节点的etcd会以新的client URLs对外提供服务。节点的client URLs更新出现错误时，不会影响集群的健康状态

更新节点advertise peer URLs

要更新某个节点的advertise peer URLs，需要显示的通过etcdctl的member命令更新peer-urls参数，然后重启该节点。由于节点peer URLs涉及到的的是集群范围的配置变更，操作不当会影响集群的健康状态，所以要规范操作

  • 首先通过etcdctl的member list命令获取节点ID
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member list
6e3bd23ae5f1eae0: name=node2 peerURLs=http://localhost:23802 clientURLs=http://127.0.0.1:23792
924e2e83e93f2560: name=node3 peerURLs=http://localhost:23803 clientURLs=http://127.0.0.1:23793
a8266ecf031671f3: name=node1 peerURLs=http://localhost:23801 clientURLs=http://127.0.0.1:23791
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member update a8266ecf031671f3 --peer-urls=http://10.0.1.10:2380

Updated member with ID a8266ecf031671f3 in cluster
  • 修改etcd的peer urls参数，然后重启etcd

删除一个节点

假设要删除的节点ID是a8266ecf031671f3，使用member remove命令移除节点

etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member remove a8266ecf031671f3

节点a8266ecf031671f3会自动停止并退出，并输出如下日志
etcd: this member has been permanently removed from the cluster. Exiting.
移除leader节点也是安全的，但在新的leader选举出来前，集群是不可用的

增加一个节点

增加一个节点分为两步：

  • 通过etcdctl member add指令将新的成员添加到集群当中，告诉集群新的成员信息，例如新成员的名字，peer urls
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member add infra3 --peer-urls=http://10.0.1.13:2380
输出如下信息：
added member 9bf1b35fc7761a23 to cluster
ETCD_NAME="infra3"
ETCD_INITIAL_CLUSTER="infra0=[http://10.0.1.10:2380](http://10.0.1.10:2380/),infra1=[http://10.0.1.11:2380](http://10.0.1.11:2380/),infra2=[http://10.0.1.12:2380](http://10.0.1.12:2380/),infra3=[http://10.0.1.13:2380](http://10.0.1.13:2380/)"
ETCD_INITIAL_CLUSTER_STATE=existing

该命令已通知集群新加入的节点信息，并打印出了新节点加入时需要配置的环境变量信息，新节点需要配置这些环境变量才能成功启动

  • 使用新的集群配置信息启动新加入的成员
$ export ETCD_NAME="infra3"
$ export ETCD_INITIAL_CLUSTER=”infra0=http://10.0.1.10:2380, infra1=http://10.0.1.11:2380, infra2=http://10.0.1.12:2380, infra3=http://10.0.1.13:2380”
$ export ETCD_INITIAL_CLUSTER_STATE=existing
$ etcd --listen-client-urls http://10.0.1.13:2379 --advertise-client-urls http://10.0.1.13:2379 --listen-peer-urls http://10.0.1.13:2380 --initial-advertise-peer-urls http://10.0.1.13:2380 --initial-cluster="infra0=http:// 10.0.1.10:2380, infra1=http:// 10.0.1.11:2380, infra2=http:// 10.0.1.12:2380, infra3=http:// 10.0.1.13:2380" --data-dir %data_dir%

新节点启动完成后，就会立即同步其他的节点
注意，"initial-cluster"里面一定要有新成员的peer地址，因为etcdctl执行完毕"etcdctl member add"后，etcd cluster就把这个还未存在的node算进quorum了，第二步必须准确完成
如果要新增多个节点时，最好是一次新增一个，并且需要确保新增的节点正常启动且运行正常后在新增下一个节点。
如果是向只有一个节点的集群新增节点，在执行member add命令后，新节点正常启动并与已存在的节点建立连接之前，集群不会继续执行数据的提交工作，因为此时集群在等待多数节点达成共识

新增节点可能遇到的error case

  • 新增节点在启动时没有将新节点的peer urls加入到启动参数--initial-cluster参数中，则新节点会启动失败
etcd --name infra3 --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380  --initial-cluster-state existing
输出信息如下：
etcdserver: assign ids error: the member count is unequal
exit 1
  • 新增节点启动时，启动参数中给了一个错误的peer urls。例如，将正确的地址10.0.1.13:2380误写为10.0.1.14:2380
$ etcd --name infra4 --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra4=http://10.0.1.14:2380 --initial-cluster-state existing 
输出信息如下  
etcdserver: assign ids error: unmatched member while checking PeerURLs   
exit 1

磁盘空间限额

Etcd的space quota可以保证集群已可靠的方式运行。如果不配置space quota，etcd的key存储空间可能会过度的增长导致性能下降，甚至在超过磁盘的可用空间时，导致不可预期的行为。如果任何一个节点的后端数据库大小超过space quota时，etcd会产生一个集群范围的告警，使集群进入一种维护状态，在这种状态下，集群只接受key的读取和删除，只有在释放了足够的key值或者对数据库进行碎片整理后，集群才能进入正常工作状态
通过以下启动参数配置keyspace使用的空间限额

# set a very small 16MB quota
$ etcd --quota-backend-bytes=$((16*1024*1024))

与运行环境有关的faq

"apply entries took too long"

etcd集群接受一个写请求后，每个etcd成员都需要把写请求数据固化到cores/bbolt之中，整个过程不要超过50ms。如果超过100ms，则etcd就会打印此条log进行警告。通常情况下是因为磁盘慢，比如磁盘竞争或者譬如虚拟块磁盘这种烂设备。etcd暴露给Prometheus的metrics指标backendcommitduration_seconds就显示了commit的瓶颈时间，这个指标低于25ms即可认为服务正常，如果磁盘本身确实慢则设置一个etcd专用磁盘或者更换成SSD通常就能解决问题。
第二个原因是CPU计算力不足。如果是通过监控系统发现CPU利用率确实很高，就应该把etcd移到更好的机器上，然后通过cgroups保证etcd进程独享某些核的计算能力，或者提高etcd的priority。

"failed to send out heartbeat on time"

etcd使用了raft算法，leader会定时地给每个follower发送心跳，如果leader连续两个心跳时间没有给follower发送心跳，etcd会打印这个log以给出告警。通常情况下这个issue是disk运行过慢导致的，leader一般会在心跳包里附带一些metadata，leader需要先把这些数据固化到磁盘上，然后才能发送。写磁盘过程可能要与其他应用竞争，或者因为磁盘是一个虚拟的或者是SATA类型的导致运行过慢，此时只有更好更快磁盘硬件才能解决问题。etcd暴露给Prometheus的metrics指标walfsyncduration_seconds就显示了wal日志的平均花费时间，通常这个指标应低于10ms。
第二种原因就是CPU计算能力不足。如果是通过监控系统发现CPU利用率确实很高，就应该把etcd移到更好的机器上，然后通过cgroups保证etcd进程独享某些核的计算能力，或者提高etcd的priority。
第三种原因就可能是网速过慢。如果Prometheus显示是网络服务质量不行，譬如延迟太高或者丢包率过高，那就把etcd移到网络不拥堵的情况下就能解决问题。但是如果etcd是跨机房部署的，长延迟就不可避免了，那就需要根据机房间的RTT调整heartbeat-interval，而参数election-timeout则至少是heartbeat-interval的5倍。

"snapshotting is taking more than x seconds to finish ..."

etcd会把kv snapshot发送给一些比较慢的follow或者进行数据备份。慢的snapshot发送会拖慢系统的性能，其自身也会陷入一种活锁状态：在很慢地收完一个snapshot后还没有处理完，又因为过慢而接收新的snapshot。当发送一个snapshot超过30s并且在1Gbps(千兆)网络环境下使用时间超过一定时间时，etcd就会打印这个日志进行告警。

"request ignored (cluster ID mismatch)"

etcd cluster启动的时候通过"initial-cluster-token"参数指定集群的名称。如果一个老集群已经tear down，但是还有部分成员活着，此时在老集群之上又部署新的集群之后，那些还活着的老成员会尝试连接新集群的各个成员，因为cluster token不一致新成员接收到请求后会报出这个warning。
避免这个错误的方法就是不要使用老集群的地址。

etcd 对时间很依赖，所以集群里的节点时间一定要同步

etcd集群出现unhealthy的节点处理

如果raft集群中有处于unhealthy状态的node，需要先把它剔除掉，然后才能进行替换操作。但是添加一个新的node是一件非常高风险的操作：如果一个3节点的etcd集群有一个unhealthy node，此时没有先把unhealthy node剔除掉，而新添加节点时可能由于配置不当或者其他原因导致新的node添加失败，则新集群理论上node number为4而当前quorum只可能达到2，失去consensus的集群对任何操作都无法达成共识。
如果按照正确的操作步骤，先剔除 unhealthy node，此时n为2而quorum为2，添加新节点后n为 3，及时添加新节点失败也不会导致集群不可用。

etcd集群实践

集群状态查看

集群的初始状态如上图，集群已经过多次反复重启，leader选举已发生了1196次
向集群写入一次数据，RAFT INDEX会加1，RAFT TERM表示的是leader选举的轮数，只有重新发生leader选举，RAFT TERM才会增加。Etcd的--snapshot-count=100，以便于观察snap的生成规律，生产环境推荐10000。此时RAFT INDEX为45，snap文件夹下还未生成snap文件
通过以下命令，向集群提交100次写入操作

for i in {1..100}
do
export ETCDCTL_API=3;etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE put hello world$i
done

可以看到，RAFT INDEX增加了100，与提交给集群的写入次数相同，并且集群生成了一个快照文件00000000000004ac-0000000000000065.snap，其中00000000000004ac是RAFT TERM 1196的十六进制表示，0000000000000065是生成snap时，对应的RAFT INDEX的十六进制表示，0x65=101
执行以下命令两次

for i in {1..110}
do
export ETCDCTL_API=3;etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE put hello world$i
done

再向etcd写入220次数据，又生成了两个snap文件，其中文件名的后半部分0xca=202, 0x12f=303,所以当RAFT INDEX能整除--snapshot-count=100这个变量时，就会生成一个snap文件

备份操作

执行以下命令进行数据备份

export ETCDCTL_API=3;etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE snapshot save cluster1_1198_366_49k.db

命令执行成功后，会生成数据文件cluster1_1198_366_49k.db，该文件可用于集群恢复，其中1198是RAFT TERM,366是RAFT INDEX，用于记录集群当前的两个状态

从备份数据恢复集群

执行下面的脚本，从备份的数据恢复集群，执行成功后，会在各自--data-dir指定的目录中生成数据目录

restore-etcd-cluster.sh
etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra4 
--data-dir=/var/lib/etcd/infra4 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23804
etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra5 
--data-dir=/var/lib/etcd/infra5 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23805
etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra6 
--data-dir=/var/lib/etcd/infra6 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23806

其中infra4、infra5、infra6是新生成的3个节点的数据目录
分别执行以下3个脚本，来从恢复的数据目录中启动

start4.sh
#!/bin/bash
node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra4
etcd 
--name=infra4 
--initial-advertise-peer-urls=https://$node4:23804 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node4:23804 
--listen-client-urls=https://$node4:23794 
--advertise-client-urls=https://$node4:23794 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806

start5.sh

#!/bin/bash

node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra5

etcd 
--name=infra5 
--initial-advertise-peer-urls=https://$node5:23805 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node5:23805 
--listen-client-urls=https://$node5:23795 
--advertise-client-urls=https://$node5:23795 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806
start6.sh

#!/bin/bash

node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra6
etcd 
--name=infra6 
--initial-advertise-peer-urls=https://$node6:23806 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node6:23806 
--listen-client-urls=https://$node6:23796 
--advertise-client-urls=https://$node6:23796 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806

恢复集群启动成功后，查看之前写入hello对应的值为world110，正是我们之前备份前最后写入的值，说明集群恢复是正确的

更新节点advertise client URLs

测试目标：将测试集群中node6的client urls端口由23796改为23797
更改start6.sh脚本中的对应行如下：

--listen-client-urls=https://$node6:23797 
--advertise-client-urls=https://$node6:23797

Kill掉node6节点的etcd，后再执行start6.sh启动node6
重新启动后，node6的client urls已经更新

更新节点的peer urls

测试目标：将测试集群中node6的peer urls端口由23806改为23807

  • 更改start6.sh脚本中的对应行如下
--initial-advertise-peer-urls=https://$node6:23807    
--listen-peer-urls=https://$node6:23807   
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23807
  • 通过member list指令获取node id
  • 通过member update更新node的peer urls
  • Kill node6节点，再使用更新后的start6.sh脚本启动node6节点

测试结果如上图，node6的peer url更新成功

etcd
点赞
收藏
评论区
推荐文章
Stella981 Stella981
•
4年前
Docker Kubernetes 高可用架构设计
DockerKubernetes高可用架构设计官方方案：保证master端不发生单点故障。官方使用一台LoadBalancer负载均衡代理3台master端，终端与etcd与workNode节点，通过负载均衡的ip进行连接。master端的所有信息都会统一保存到etcd的存储内。!(https://o
1315
0
0
京东云开发者 京东云开发者
•
3年前
分布式注册服务中心etcd在云原生引擎中的实践
作者：王雷etcd是什么etcd是云原生架构中重要的基础组件，由CNCF孵化托管。ETCD是用于共享配置和服务发现的分布式，一致性的KV存储系统，是CoreOS公司发起的一个开源项目，授权协议为Apache。etcd基于Go语言实现，主要用于共享配置，服务
850
0
0
Wesley13 Wesley13
•
4年前
ETCD：配置参数
原文地址：Configurationflags(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fgithub.com%2Fetcdio%2Fetcd%2Fblob%2Fmaster%2FDocumentation%2Fopguide%2Fconfiguration.md)etcd
1837
0
0
Wesley13 Wesley13
•
4年前
Java中使用etcd，包括基本的set、get、超时设置，watch监听等
etcd的使用文章。etcd来zookeeper类似，常用的主要有set，get，getPrefix：获取指定前缀的所有数据，grant：key的超时设置，watch：监听回调事件，watchPrefix：监听某个前缀的事件，keepAlive：为某个key设置自动续约、自动刷新过期时间。zk的大部分功能，etcd都有。但有一个，譬如虚拟节点，zk可
1424
0
0
Stella981 Stella981
•
4年前
Kubernetes学习之路（三）之Mater节点二进制部署
K8SMater节点部署1、部署KubernetesAPI服务部署apiserver提供集群管理的RESTAPI接口，包括认证授权、数据校验以及集群状态变更等。只有APIServer才能直接操作etcd；其他模块通过APIServer查
1039
0
0
Stella981 Stella981
•
4年前
Docker在服务器重启后自动运行
导读CoreOS服务器有时会系统自动升级，在系统重启后，如何将部署的程序也自动随时系统启动呢？还有Etcd和Flannel。1、设置Flannel的Unit文件，在Etcd服务启动后启动；把相关配置工作放到Unit文件中，如添加ExecStartPost参数UnitDescriptionflannelAfterdocke
1026
0
0
Wesley13 Wesley13
•
4年前
K8S各知识点整理
一、k8s组成部分Master1、  kubeapiserver封装了核心对象的增删改查操作，以RESTAPI接口方式提供给外部和内部组件调用。它维护的REST对象将持久化到Etcd中2、  kubecontroller负责执行各种控制器，目前已经实现很多控制器来
1000
0
0
Stella981 Stella981
•
4年前
CenotOS7.3上安装Kubernates1.11容器(一主多从)
1.服务器规划 部署节点etcd节点master节点node节点192.168.0.101是是是 192.168.0.102   是192.168.0.103   是192.168.0.104   
1026
0
0
Wesley13 Wesley13
•
4年前
.Net Core Configuration Etcd数据源
前言    .NetCore为我们提供了一套强大的Configuration配置系统，使用简单扩展性强。通过这套配置系统我们可以将Json、Xml、Ini等数据源加载到程序中,也可以自己扩展其他形式的存储源。今天我们要做的就是通过自定义的方式为其扩展Etcd数据源操作。何为Etdc    在使用etcd之前我们先介绍一下Etcd
1088
0
0
Stella981 Stella981
•
4年前
Kubernetes集群安装(自己搭过，已搭好)
k8s安装目录1\.组件版本&&集群环境组件版本etcd集群&&k8smaster机器&&k8snode机器集群环境变量2\.创建CA证书和密钥安装
1169
0
0
Stella981 Stella981
•
4年前
K8S之adm集群证书过期和集群升级一并解决
作者：李毓k8s的adm安装方式有一个巨坑，就是证书过期问题。其中涉及到的证书有apiserver,kubelet,etcd,proxy等等证书。这个问题在二进制安装方式是不存在的，因为可以手动更改证书。但是由于adm是自动安装，所以需要后期处理。目前的解决方式一般有三种，第一种是集群升级，通过升级k8s，间接的把证书也升级了。第二种是
1184
0
0
ByteObsidianVoyantPro
ByteObsidianVoyantPro
Lv1
人归落雁后，思发在花前。
文章
5
粉丝
0
获赞
0
热门文章
用golang编写一个短链接服务
nodejs入门
5、Azure DevOps之Azure Test Plans篇
《Linux网络开发必学教程》24_物联网服务模块实现（非必要）