这是非云环境中Kubernetes的配置和运行系列的第六篇文章,本文将详细阐释etcd的技术细节,及其在Kubernetes集群中的作用。
etcd是一种为集群内各机器提供可靠数据存储的分布式键值存储。etcd开源提供在GitHub上,它很好地解决了网络分区期间领导者的选举问题,可容忍包括领导者节点在内的节点故障。
引用自: https://coreos.com/etcd/docs/latest/
etcd以驻留内存进程形式运行在集群中的每台机器上,提供动态配置的记录,支持以简单方式在集群成员间共享多种配置数据。
etcd以键值方式存储数据,它是分布式的,支持自动复制和领导者自动选举产生。对存储数据的所有更改,会自动反映到整个集群。 etcd还提供发现服务,支持“已部署的”应用向集群所有成员广播其所提供的服务。 etcd使用基于HTTP的JSON方式通过API调用实现通信。API可直接通过curl或wget等方式使用,也可以通过etcdctl间接使用。
参考资料: https://etcd.io/
推荐奇数个集群成员,即维持奇数规模的集群成员。无需更改获得多数所需的成员,但额外添加成员可增加对失败的容忍。对于集群成员应选奇数还是偶数时,实践出真知。
参考资料: https://coreos.com/etcd/docs/latest/v2/admin_guide.html
在计算机科学中,状态机复制(也称为“状态机方法”)是一种通过服务器复制并协调客户与服务器间的副本交互实现容错服务的通用方法。该方法还为副本管理协议的理解和设计提供了框架。
参考文献: https://en.wikipedia.org/wiki/State_machine_replication
Raft共识算法在设计上易于理解,它具有和Paxos一样的容错和性能。不同之处在于,Raft将问题分解为相对独立的子问题,并很好地解决了系统运行实际所需的关键问题。我们希望Raft共识能得到更广泛的采用,进而开发出更多基于共识的高质量系统,满足当前的需求。
参考链接: https://raft.github.io/
从前有个王国,称为“集群之地”(Cluster Land)。王国由一位非常民主的国王统治,他受由九位非常智慧、忠诚的智者团的支持 。 一旦有王国的臣民向国王提出请求,国王都会先与他的智者团商议,然后再决定是否批准该请求。如果多数智者都投了赞成票,那么该请求将获得批准。否则,将被拒绝。
上面简单比喻了Raft算法将事务提交到日志的做法。所有请求均由领导者(即国王)处理,并且仅在得到多数智者(集群中的其他节点)赞成后才能提交。
一天,国王在与一条可怕的龙作战时殉国。智者团决定无需等待任何哀悼期,应立刻选举他们中的一位作为新的国王统治者。九位智者中,有两位(暂称为其为五号和七号)申请成为新国王。在经过快速选举后,有四位智者投票赞成五号,而三位投票赞成七号。这样,五号就成为了新的国王,开始继续执行与上任国王相同的政策。
这大致说明了Raft算法中时如何进行领导者选举的。
一段时间后,由于对新统治者治理王国的方式产生了不满,一些智者发动了叛乱,最终原王国一分为二。由五号统治的“集群北地”,和由七号统治的“集群南地”,每个王国具有自己的国王和智者。原臣民生活在其中一个王国,并向各自的国王提出请求。分裂的王国依然延用相同的统治方法,即请求直接提交国王,并由各自智囊团进行磋商达成决议。 多年后,两位国王达成协议,王国得到统一。“集群之地”再次成为一个王国,由五号重新统治。不幸的是,在分裂期间,每个王国都制定了一些相互抵触的法律。为解决这个问题,智囊们同意通过遵循最新颁布的相应法律,解决所有的法律冲突。
这部分故事比喻了发生网络分区的情况。这时集群被拆分,每个新集群都有其自己的领导者和节点。冲突的请求可由各个的集群在不同的时间处理。当集群再次合并时,需要给出解决冲突值的方法。在Raft中,引入了Term概念解决分区一致性问题。
etcd存储kubernetes的设置、状态和元数据。考虑到Kubernetes是一种分布式系统,使用分布式数据库是非常必要的。正如前文所阐释的,etcd是一个具有高可用性和可扩展性的分布式数据库。
“在集群之地王国中,Raft和etcd是天作之合。”
原文链接:
领取专属 10元无门槛券
私享最新 技术干货