常州网站推广软件信息,网站维护建设招标,网站建设改版攻略,响应式网站代码规范什么是etcd? Etcd 是 CoreOS 团队于2013年6月发起的开源项目#xff0c;它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法#xff0c;Etcd基于 Go 语言实现。 名字由来#xff0c;它源于两个方面#xff0c;unix的“/etc”文件…
什么是etcd? Etcd 是 CoreOS 团队于2013年6月发起的开源项目它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法Etcd基于 Go 语言实现。 名字由来它源于两个方面unix的“/etc”文件夹和分布式系统(“D”istribute system)的D组合在一起表示etcd是用于存储分布式配置的信息存储服务。 Kubernetes 为什么用 etcd ? 2014年6月Google 的 Kubernetes 项目诞生了我们前面所讨论到 Go 语言编写、etcd 高可用、Watch 机制、CAS、TTL等特性正是 Kubernetes 所需要的它早期的0.4版本使用的正是 etcd v0.2版本。 Kubernetes 是如何使用 etcd v2 这些特性的呢举几个简单小例子。 当你使用 Kubernetes 声明式 API 部署服务的时候Kubernetes 的控制器通过 etcd Watch 机制会实时监听资源变化事件对比实际状态与期望状态是否一致并采取协调动作使其一致。Kubernetes 更新数据的时候通过 CAS 机制保证并发场景下的原子更新并通过对 key 设置 TTL 来存储 Event 事件提升Kubernetes 集群的可观测性基于 TTL 特性Event 事件 key 到期后可自动删除。 Kubernetes 项目使用etcd除了技术因素也与当时的商业竞争有关。CoreOS 是 Kubernetes 容器生态圈的核心成员之一。 Etcd 版本变化
时间轴 随着 Kubernetes 项目不断发展v2 版本的瓶颈和缺陷逐渐暴露遇到了若干性能和稳定性问题 2016年6月etcd 3.0 诞生随后 Kubernetes 1.6 发布默认启用 etcd v3助力 Kubernetes 支撑5000节点集群规模 v3方案的发布也标志着 etcd 进入了技术成熟期成为云原生时代的首选元数据存储产品。
基础架构 按照分层模型etcd 可分为 Client 层、API 网络层、Raft 算法层、逻辑层和存储层。 Client 层Client 层包括 client v2 和 v3 两个大版本 API 客户端库提供了简洁易用的 API同时支持负载均衡、节点间故障自动转移可极大降低业务使用etcd复杂度提升开发效率、服务可用性。 API 网络层API 网络层主要包括 client 访问 server 和 server 节点之间的通信协议。一方面client 访问 etcd server 的 API 分为 v2 和 v3 两个大版本。v2 API 使用 HTTP/1.x 协议v3 API 使用 gRPC 协议。同时 v3 通过 etcd grpc-gateway 组件也支持 HTTP/1.x 协议便于各种语言的服务调用。另一方面server 之间通信协议是指节点间通过Raft算法实现数据复制和Leader选举等功能时使用的HTTP协议。 Raft 算法层Raft 算法层实现了 Leader 选举、日志复制、ReadIndex 等核心算法特性用于保障 etcd 多个节点间的数据一致性、提升服务可用性等是etcd的基石和亮点。 功能逻辑层etcd 核心特性实现层如典型的 KVServer 模块、MVCC 模块、Auth 鉴权模块、Lease 租约模块、Compactor 压缩模块等其中 MVCC 模块主要由 treeIndex 模块和 boltdb 模块组成。 存储层存储层包含预写日志(WAL)模块、快照(Snapshot)模块、boltdb 模块。其中 WAL 可保障 etcd crash 后数据不丢失boltdb 则保存了集群元数据和用户写入的数据。 常用术语 Raftetcd 所采用的保证分布式系统强一致性的算法。 Node一个 Raft 状态机实例。 Member一个 etcd 实例。它管理着一个 Node并且可以为客户端请求提供服务。 Cluster由多个 Member 构成可以协同工作的 etcd 集群。 Peer对同一个 etcd 集群中另外一个 Member 的称呼。 Client向 etcd 集群发送 HTTP 请求的客户端。 WAL预写式日志etcd 用于持久化存储的日志格式。 snapshotetcd 防止 WAL 文件过多而设置的快照存储 etcd 数据状态。 Proxyetcd 的一种模式为 etcd 集群提供反向代理服务。 LeaderRaft 算法中通过竞选而产生的处理所有数据提交的节点。 Follower竞选失败的节点作为 Raft 中的从属节点为算法提供强一致性保证。 Candidate当 Follower 超过一定时间接收不到 Leader 的心跳时转变为 Candidate 开始竞选。 Term某个节点成为 Leader 到下一次竞选时间称为一个 Term。 Index数据项编号。Raft 中通过 Term 和 Index 来定位数据。 etcdctl 常用命令
全局参数
ETCD_CA_CERT/etc/kubernetes/pki/etcd/ca.crt
ETCD_CERT/etc/kubernetes/pki/etcd/server.crt
ETCD_KEY/etc/kubernetes/pki/etcd/server.key
HOST_1https://xxx.xxx.xxx.xxx:2379
使用示例:ETCDCTL_API3 etcdctl --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} \--endpoints${HOST_1} endpoint status --write-outtable
常用命令
1. 键值操作
# 增 改
put foo bar
# 查
get foo
# 根据前缀查询
get --prefix /demo
# 查询所有 keys
get --prefix --keys-only
# 删
del foo
# 事务多个操作合并为一个事务
txn mod(key1) 0put key1 overwrote-key1put key1 created-key1
put key2 some extra key
# 压缩
compaction 1234
# 监听
watch foo
2. 集群维护
# 列出成员
member list
# 端点健康情况
endpoint health
# 端点状态
endpoint status
# 告警列表
alarm list
# 解除所有告警
alarm disarm
# 碎片整理
defrag
# 创建快照进行备份
snapshot save snapshot.db
# 快照恢复
snapshot restore
# 快照状态
snapshot status
etcd监控
重点监控指标
指标分类 健康状态 USE 方法系统 使用率 饱和度 错误 RED 方法应用 请求速率 错误率 延迟
指标分类指标释义健康状态实例健康状态etcd是一个分布式系统由多个成员节点组成。监控etcd成员节点的状态可以帮助你了解集群中节点的健康状况发现掉线或者异常节点。健康状态主从状态健康状态etcd leader切换统计频繁的领导者变更会严重影响 etcd 的性能。这也意味着领导者不稳定可能是由于网络连接问题或对 etcd 集群施加的过载负荷导致的。健康状态心跳etcd集群中的节点通过发送心跳来保持彼此之间的连接。监控丢失的心跳可以帮助你发现etcd节点之间的通信问题或者网络延迟。RED 方法QPSRED 方法请求错误率监控etcd的错误率可以帮助你发现etcd操作中的潜在问题。高错误率可能表明集群遇到了故障或其他异常情况。RED 方法请求延迟监控etcd的请求延迟可以帮助你了解API请求的处理时间。较高的延迟可能表明etcd正面临负载压力或性能问题。RED 方法磁盘同步WAL/DB fsync耗时高磁盘操作延迟wal_fsync_duration_seconds或backend_commit_duration_seconds通常表示磁盘问题。它可能会导致高请求延迟或使群集不稳定。RED 方法同步延迟如果集群正常运行已提交的提案应该随着时间的推移而增加。重要的是要在集群的所有成员中监控这个指标如果单个成员与其领导节点之间存在持续较大的滞后这表明该成员运行缓慢或存在异常。RED 方法提案失败次数失败的提案通常与两个问题相关与领导选举相关的暂时性故障或由于集群丧失法定人数而导致的较长时间的停机。RED 方法快照处理时间etcd定期创建快照以备份数据。监控快照处理时间可以帮助你了解etcd备份的性能确保备份任务能够及时完成。RED 方法watcher 数量监控etcd集群当前连接到etcd的客户端数量。如果连接数过高可能需要调整etcd的配置或者增加集群的容量。USE 方法CPU 使用率USE 方法内存使用量USE 方法打开文件数USE 方法存储空间使用率监控etcd存储空间的使用率可以帮助你确保etcd有足够的空间存储配置数据。如果使用率接近或达到上限可能需要考虑扩展存储容量或者清理无用的数据。
使用 kube-prometheus 收集 etcd 指标 http 模式推荐
修改--listen-metrics-urls
#- --listen-metrics-urlshttp://127.0.0.1:2381- --listen-metrics-urlshttp://127.0.0.1:2381,http://ip:2381# 部署helm install monitoring -n cattle-prometheus --set kubeEtcd.service.port2381 --set kubeEtcd.service.targetPort2381 --set prometheusOperator.admissionWebhooks.patch.image.shanull ./ https 模式
新增 etcd secret
kubectl create secret generic etcd-certs -n cattle-prometheus --from-file/etc/kubernetes/pki/etcd/ca.crt --from-file/etc/kubernetes/pki/etcd/healthcheck-client.crt --from-file/etc/kubernetes/pki/etcd/healthcheck-client.key# 部署helm install monitoring -n cattle-prometheus --set kubeEtcd.serviceMonitor.schemehttps --set kubeEtcd.serviceMonitor.caFile/etc/prometheus/secrets/etcd-certs/ca.crt --set kubeEtcd.serviceMonitor.certFile/etc/prometheus/secrets/etcd-certs/healthcheck-client.crt --set kubeEtcd.serviceMonitor.keyFile/etc/prometheus/secrets/etcd-certs/healthcheck-client.key --set prometheus.prometheusSpec.secrets{etcd-certs} --set prometheusOperator.admissionWebhooks.patch.image.shanull ./大盘展示
Grafana 大盘https://github.com/clay-wangzhi/grafana-dashboard/blob/master/etcd/etcd-dash.json
监控指标补充 数据一致性、写请求、资源对象数等 收集过程详见https://github.com/clay-wangzhi/etcd-metrics
参考 https://github.com/kstone-io/kstone 进行裁剪
Etcd 基准测试
SLI SLO SLIService Level Indicator服务等级指标其实就是我们选择哪些指标来衡量我们的稳定性。 SLOService Level Objective服务等级目标指的就是我们设定的稳定性目标比如“几个 9”这样的目标。 SLO 是 SLI 要达成的目标我们需要选择合适的 SLI设定对应的 SLO。
SLISLO测试方式吞吐量衡量etcd每秒可以处理的请求数量每秒处理40,000个读取请求和20,000个写入请求官方 benchmark响应时间衡量etcd对于读取和写入请求的响应时间99%的读写请求在100毫秒以内完成官方 benchmark
使用 benchmark 测试延迟和吞吐量
1. 安装golang环境
wget https://golang.google.cn/dl/go1.19.10.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.19.10.linux-amd64.tar.gz# 配置环境变量vim /etc/profileexport PATH$PATH:/usr/local/go/bin
export GOPROXYhttps://goproxy.cnsource /etc/profile# 检查验证go version 2. 安装 benchmark 工具
git clone https://github.com/etcd-io/etcd.git --depth 1
cd etcd/
go install -v ./tools/benchmark
# 找到二进制文件位置
go list -f {{.Target}} ./tools/benchmark
3. 基准测试
# 查看帮助信息cd /root/go/bin/./benchmark -h# 配置环境变量ETCD_CA_CERT/etc/kubernetes/pki/etcd/ca.crt
ETCD_CERT/etc/kubernetes/pki/etcd/server.crt
ETCD_KEY/etc/kubernetes/pki/etcd/server.key
HOST_1https://xxx.xxx.xxx.xxx:2379
HOST_2https://xxx.xxx.xxx.xxx:2379
HOST_3https://xxx.xxx.xxx.xxx:2379# 提前写个测试 key
YOUR_KEYfoo
ETCDCTL_API3 /usr/local/bin/etcdctl --endpoints${HOST_1},${HOST_2},${HOST_3} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} put $YOUR_KEY bar
写测试
# write to leader./benchmark --endpoints${HOST_2} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --target-leader --conns1 --clients1 \put --key-size8 --sequential-keys --total10000 --val-size256./benchmark --endpoints${HOST_2} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --target-leader --conns100 --clients1000 \put --key-size8 --sequential-keys --total100000 --val-size256# write to all members./benchmark --endpoints${HOST_1},${HOST_2},${HOST_3} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --conns100 --clients1000 \put --key-size8 --sequential-keys --total100000 --val-size256
读测试
# Single connection read requests./benchmark --endpoints${HOST_1},${HOST_2},${HOST_3} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --conns1 --clients1 \range $YOUR_KEY --consistencyl --total10000./benchmark --endpoints${HOST_1},${HOST_2},${HOST_3} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --conns1 --clients1 \range $YOUR_KEY --consistencys --total10000# Many concurrent read requests./benchmark --endpoints${HOST_1},${HOST_2},${HOST_3} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --conns100 --clients1000 \range $YOUR_KEY --consistencyl --total100000./benchmark --endpoints${HOST_1},${HOST_2},${HOST_3} --cacert${ETCD_CA_CERT} --cert${ETCD_CERT} --key${ETCD_KEY} --conns100 --clients1000 \range $YOUR_KEY --consistencys --total100000
使用 FIO 测试磁盘性能
Etcd 对内存和 CPU 消耗并不高足够就行
一次 Etcd 请求的最小时间 成员节点之间的网络往返时延 收到数据之后进行持久化的时延。因此Etcd 的性能主要受两方面的约束 网络 磁盘
多节点的 Etcd 集群成员节点应该尽量部署在同一个数据中心减少网络时延。同一数据中心内不同节点的网络情况通常是非常好的如果需要测试可以使用 ping 或 tcpdump 命令进行分析。
存储性能能够满足 etcd 的性能要求有两种方法测试 1. 已运行的 etcd 集群通过指标etcd_disk_wal_fysnc_duration_seconds来评估存储 I/O 性能 该指标记录了 WAL 文件系统调用 fsync 的延迟分布当 99% 样本的同步时间小于 10 毫秒就可以认为存储性能能够满足 etcd 的性能要求。 2. 用 fio 命令还原 etcd 使用场景看99线 mkdir test-datafio --rwwrite --ioenginesync --fdatasync1 --directorytest-data --size22m --bs2300 --namemytest如何调优 1. 硬盘
使用SSD固态硬盘
给定较高的磁盘优先级
# best effort, highest priority
$ sudo ionice -c2 -n0 -p pgrep etcd
2. CPU
CPU 性能模式调整为 performance , 如何调整不成功参考https://clay-wangzhi.com/cloudnative/troubleshooting/vm-vs-container-performance.html#cpu
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor3. 配置参数优化
开启自动压缩、修改etcd raft消息最大字节数、修改 etcd最大容量等。
参考资料
github etcdctl dochttps://github.com/etcd-io/etcd/blob/main/etcdctl/README.md
datadog etcd 指标https://docs.datadoghq.com/integrations/etcd/?tabhost
etcd 官方文档-tunninghttps://etcd.io/docs/v3.5/tuning/
etcd 官方文档-硬件要求https://etcd.io/docs/v3.5/op-guide/hardware/
etcd 官方文档-benchmarkhttps://etcd.io/docs/v3.5/benchmarks/etcd-3-demo-benchmarks/
使用fio测试etcd是否满足要求https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd
