CoreOS发布etcd v2.3.0,重点提升稳定性和可靠性

简介: 本文讲的是CoreOS发布etcd v2.3.0,重点提升稳定性和可靠性,【编者的话】Etcd v2.3.0正式发布了!这次更新不仅伴随着稳定性和可靠性方面的提升,还为我们带来了新的v3版本API的预览版以及新的存储引擎,除此之外还有哪些诱人的特性呢?赶紧来看看吧!
本文讲的是CoreOS发布etcd v2.3.0,重点提升稳定性和可靠性 【编者的话】Etcd v2.3.0正式发布了!这次更新不仅伴随着稳定性和可靠性方面的提升,还为我们带来了新的v3版本API的预览版以及新的存储引擎,除此之外还有哪些诱人的特性呢?赶紧来看看吧!

今天,我们很高兴地宣布etcd v2.3.0正式发布了,这次更新的重点放在稳定性和可靠性方面的改进。这个版本里同样也推出了一个实验性的下一代v3版本API的实现,包括一个客户端和命令行工具,为开发者们提供未来版本etcd的提前体验。

etcd 是一款开源的分布式一致性键值存储。数以百计的项目使用etcd来完成共享配置,服务发现,协同调度等,同时etcd也是CoreOS栈的一个重要组成部分。它还是 Kubernetes 集群编排系统主要的调度和服务发现的数据存储。

你可以 转到etcd社区来了解关于etcd的更多内容,并且可以在Github上找到新版本的可执行程序 。想了解关于这次最新更新的详细内容请接着往下看。

稳定的认证API

我们在几个月前推出了V2版 授权API 的实验版本。自那以后,通过实际环境的测试使得etcd的认证API变得稳定,并且在生产环境使用的可靠性以及和开发的集成方面已然就绪。该认证API提供了一个识别用户并基于该身份在etcd集群里授权对应功能的机制。

缩短延迟高达2倍

为了确保持久性,一个etcd集群会在每个请求过来时在答复它之前先将其持久化到该集群里大部分成员的磁盘里。此前,这一磁盘I/O在etcd领导者和它的追随者之间是以顺序执行的方式发生,因此最小的延迟会是 2 * fsync latency + network latency 。为了减少这样潜在的瓶颈,我们实现了一个在 Raft论文 中提到过的优化策略。etcd 2.3.0版本取而代之的是在领导者和它的追随者之间以并行的方式完成磁盘I/O,因为追随者写的时候不需要再事先等领导者的写操作完成,所以也就意味着最小延迟为 fsync latency + network latency

功能测试仪表盘

在过去的一年里,我们把etcd放到了长期运行的 功能测试 中。我们的etcd集群已经通过了成千上万次这样的功能性测试,这里面包括杀掉节点以及丢弃网络包等测试。这些工作在检测运行时问题方面特别有帮助,我们可以借此先于用户发现这些问题,并且由此可以显著提高etcd正式版本的可靠性。

这些功能测试的最新结果如今能够在新的 etcd测试仪表盘 里公开可见。

etcdtestdash.png


该面板视图里包含了一些必不可少的统计数据,例如在这个etcd集群上自它最后一次重启起执行的所有功能测试的总共回合数

这些测试的失败率通常低于0.1%。etcd团队会去调研每一个失败的功能测试,然后利用分析结果来驱动改进etcd或者是测试基础设施本身。这些功能测试甚至能够帮助我们发现etcd依赖里面的一个 有趣bug ,然后使得我们创建一个上游的修复,惠及广大的开源社区。

最近高比例的测试失败实际上已经揭露了测试和测试环境的短板,而并非etcd。例如,在一个商业的云基础设施上运行etcd测试集群的话有时也意味着超分的虚拟资源会错误地触发一些带时序假设的测试用例失败。这些误报甚至会延伸到报告机制本身,它本来应再等两秒可是却已经将误报发送了出去。我们正在不断地努力改善它,接下来我们还会继续测试并使用这个基础设施。

v3版本API和新的存储引擎

etcd 2.3版本推出了一个实验性的全新v3版本API的实现。etcd的v3版本API旨在使得etcd能够更高效地扩展到更多的客户端。为了能够更好地支持这些新的API特性,这一版本里也加入了一个新的实验性存储引擎。这一新的存储引擎采用的是带有全 MVCC 支持的一个基于 b+树 结构的磁盘存储格式。这使得etcd能够支持增量的快照和低成本的"时间旅行"式的查询,例如像访问一个key的之前版本等操作。所有v2版本的API请求则仍然延续使用稳定的现有存储引擎和磁盘格式。只有v3版本的API操作会落在新的b+树存储系统上。v2和v3版本的API在 数据模型 上有很大的不同,并且不是那么容易做到v2和v3 API操作相同键值命名空间的同时保证API不受这两个版本的影响。因此,尽管理论上来说为这两个API使用统一的数据存储层并非不可能,但是它给现有的v2版本的用户实际带来的收益非常有限。就目前而言,分别为两个API版本维护各自的存储引擎显得更有价值,并且也简化了实现的难度。

我们并没有打算废弃v2版本的API,并且如果etcd v3版本发布的话这两个API也将会继续并排存在。我们还会为那些希望将他们的应用从etcd v2版本API平滑迁移到v3版本的开发者和用户们提供一个迁移指南。

etcd2v3storage.png


The etcd v2 and v3 API使用不同的存储引擎

开始使用etcd v3版本 API

我们非常希望得到你的反馈和参与到指导V3 API的持续开发中来。如果想尝试新的v3版本特性的话,可以在启动etcd时带上额外的--experimental-v3demo和--experimental-gRPC-add参数。如果打算将etcd v3版本集成到你的应用的话,不妨看一下客户端库的 相应文档

如果有Go的开发环境,你可以轻松地通过以下6个步骤来上手体验etcd v3版本的API:
go get github.com/coreos/etcd

cd $GOPATH/src/github.com/coreos/etcd

./build

go build -o bin/etcdctlv3 ./etcdctlv3

goreman start -f V3DemoProcfile start

./bin/etcdctlv3 put hello "v3 API"


请确认已经加入 etcd-dev邮件列表 以确保收到及时的更新推送。我们将继续致力于etcd的更新迭代并且持续开发所需的功能特性,我们也非常欢迎 你的贡献 !还没有使用etcd?从 这里 开始吧。

原文链接:CoreOS Delivers etcd v2.3.0 with Increased Stability and v3 API Preview (翻译:吴佳兴)

原文发布时间为:2016-03-27 
本文作者:colstuwjx 
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:CoreOS发布etcd v2.3.0,重点提升稳定性和可靠性
目录
相关文章
|
Kubernetes 负载均衡 网络协议
详解 Kubernetes 的稳定性和可用性
大家好,我叫杨朝乐,来自才云科技基础设施部门。今天给大家分享一个平时可能接触得较少的话题:关于 Kubernetes 的稳定性和可用性。 下面是今天分享以下 5 个主题: 认识稳定性 认识异常 Kubernetes 里面的高可用方案 如何处理异常 我的经验分享 认识稳定性 Kubernetes 集群的稳定性和众多因素相关。
2649 1
|
3天前
|
存储 运维 Kubernetes
Kubernetes 集群的持续性能优化实践
【4月更文挑战第16天】 随着容器化技术的普及,Kubernetes 已成为管理微服务架构的首选平台。但在动态变化的负载环境中保持高性能并非易事。本文将探讨一系列实用的 Kubernetes 集群性能优化策略,旨在帮助运维工程师识别和解决潜在的性能瓶颈。通过对存储、计算资源分配、网络配置以及集群规模管理的深入分析,我们将提供一套综合的性能调优框架,以支持高效、稳定的服务运行。
|
9天前
|
机器学习/深度学习 运维 Kubernetes
Kubernetes 集群的持续性能优化策略
【4月更文挑战第10天】 在容器编排领域,Kubernetes 因其强大的功能和灵活性而广受欢迎。然而,随着集群规模的扩大和应用复杂度的提升,性能优化成为了维护高效运行环境的关键挑战。本文将深入探讨针对 Kubernetes 集群的持续性能优化策略,涵盖监控、资源管理、网络优化及自动化工具的应用,旨在为运维工程师提供一套实用的调优框架,以实现更高效的服务响应和资源利用率。
|
30天前
|
运维 Kubernetes 调度
Kubernetes工作负载重点总结
Kubernetes工作负载重点总结
29 3
|
Kubernetes 安全 Cloud Native
Kubernetes 多集群管理平台 OCM v0.9.0 发布:进一步改善托管集群安全性问题
随着 OpenClusterManagement(OCM)项目的持续发展,我们觉得有必要周期性向大家同步近期项目的一些进展了,包括我们我们下一步未来发展的方向以及作为贡献者如何参与进来我们的社区。2022 年的尾声即将到来,让我们来进一步看一下项目研发方面的新内容吧!
|
存储 Prometheus Kubernetes
Kubernetes 集群和应用监控方案的设计与实践
Kubernetes 集群和应用监控方案的设计与实践
294 0
Kubernetes 集群和应用监控方案的设计与实践
|
自然语言处理 Kubernetes 监控
系统架构面临的三大挑战,看 Kubernetes 监控如何解决?
随着 Kubernetes 的不断实践落地,我们经常会遇到负载均衡、集群调度、水平扩展等问题。归根到底,这些问题背后都暴露出流量分布不均的问题。那么,我们该如何发现资源使用,解决流量分布不均问题呢?今天,我们就借助三个具体场景聊聊这一问题以及相应的解决方案。
系统架构面临的三大挑战,看 Kubernetes 监控如何解决?
|
存储 资源调度 Kubernetes
蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】
蚂蚁 Sigma 作为蚂蚁集团核心的基础设施,经过多年的发展其规模已经处于业界领先位置,大规模集群对 Kubernetes 的稳定性及功能性提出更高的要求。蚂蚁 Sigma 力争在万级规模的云原生环境下,挑战高效稳定、无损无感的云原生操作系统升级,给用户带来极致稳定的、功能新颖的云原生服务。
蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】
|
存储 Kubernetes Cloud Native
Kubernetes 稳定性保障手册 -- 可观测性专题
伴随大家对稳定性重视程度的不断提升、社区可观测性项目的火热,可观测性成为了一个很热门的话题,站在不同的角度会产生不同的理解。 我们从软件开发的生命周期出发,尝试形成对可观测性的一个宏观理解,并从 SRE 和 Serverless 两个角度具化可观测性的理解以及实践。
Kubernetes 稳定性保障手册 -- 可观测性专题
|
弹性计算 运维 Kubernetes
Kubernetes集群升级指南:从理论到实践
摘要:集群升级是Kubernetes集群生命周期中最为重要的一环,也是也是众多使用者最为谨慎对待的操作之一。为了更好地理解集群升级这件事情的内涵外延,我们首先会对集群升级的必要性和难点进行阐述。随后我们会对集群升级前必须要做的前置检查进行逐一讲解。接下来我们会对两种常见的升级方式进行展开介绍。最后我们对集群升级的三个步骤进行讲解,帮助读者从理论走入实践。   升级的必要性&a
688 0
Kubernetes集群升级指南:从理论到实践