k8s的核心组件etcd功能详解【含etcd各类参数详细说明】

本文详细介绍了k8s核心组件etcd的角色与功能,包括Leader、Follower和Candidate的职责。重点讨论了Raft算法中的Term(任期)以及日志复制和数据安全性。在数据一致性方面,文章阐述了如何通过Raft算法确保集群的正确性和数据安全。同时,还探讨了etcd在服务发现、消息发布与订阅、负载均衡、分布式锁和集群监控等应用场景中的作用。此外,文章还提供了etcd的启动参数详解,帮助读者更好地理解和配置etcd。
摘要由CSDN通过智能技术生成

Leader节点在集群中有且仅能有一个,它负责向所有的Follower节点同步日志数据。

2、Follower(跟随者):

Follower节点从Leader节点获取日志,提供数据查询功能,并将所有修改请求转发给Leader节点。(注意:由于proxy模式的本职就是启一个HTTP代理服务器,所以Etcd的代理节点(proxy)即作为Proxy角色的节点不会参与Leader的选举,只是将所有接收到的用户查询和修改请求转发到任意一个Follower或者Leader节点上。)

3、Candidate(候选者):

当集群中的Leader节点不存在或者失联之后,其他Follower节点转换为Candidate,然后开始新的Leader节点选举。

Raft算法中的Term(任期)

Raft会把时间分割成任意长度的任期,并且任期用连续的整数来标记。每一段任期都是从一次选举开始,一个或者多个候选人尝试成为领导者。如果一个候选人赢得选举,然后他就会在接下来的任期中充当Leader的职责。在某些情况下,一次选举会造成选票瓜分,这样,这一个任期将没有Leader。如果没有Leader,那么新的一轮选举就马上开始,也就是新的任期就会开始。Raft保证了在一个Term任期内,有且只有一个Leader。

在这里插入图片描述

日志复制【数据复制】

  • 是指主节点将每次操作形成日志条目,并持久化到本地磁盘,然后通过网络IO发送给其他节点。

  • 一旦一个领导人被选举出来,他就开始为客户端提供服务。客户端的每一个请求都包含一条被复制状态机执行的指令。领导人把这条指令作为一条新的日志条目附加到日志中去,然后并行的发起附加条目 RPCs 给其他的服务器,让他们复制这条日志条目。

  • Raft 算法保证所有已提交的日志条目都是持久化的并且最终会被所有可用的状态机执行。当主节点收到包括自己在内超过半数节点成功返回,那么认为该日志是可提交的(committed),并将日志输入到状态机,将结果返回给客户端。

  • 在正常的操作中,领导人和跟随者的日志保持一致性,所以附加日志 RPC 的一致性检查从来不会失败。然而,领导人崩溃的情况会使得日志处于不一致的状态(老的领导人可能还没有完全复制所有的日志条目)。这种不一致问题会在一系列的领导人和跟随者崩溃的情况下加剧。跟随者的日志可能和新的领导人不同的方式。跟随者可能会丢失一些在新的领导人中有的日志条目,他也可能拥有一些领导人没有的日志条目,或者两者都发生。丢失或者多出日志条目可能会持续多个任期。这就引出了另一个部分,就是安全性。

安全性【数据安全】

  • 选主以及日志复制并不能保证节点间数据一致。试想,当一个某个节点挂掉了,一段时间后再次重启,并当选为主节点。而在其挂掉这段时间内,集群若有超过半数节点存活,集群会正常工作,那么会有日志提交。这些提交的日志无法传递给挂掉的节点。当挂掉的节点再次当选主节点,它将缺失部分已提交的日志。在这样场景下,按Raft协议,它将自己日志复制给其他节点,会将集群已经提交的日志给覆盖掉。这显然是错误的。

  • 其他协议解决这个问题的办法是,新当选的主节点会询问其他节点,和自己数据对比,确定出集群已提交数据,然后将缺失的数据同步过来。这个方案有明显缺陷,增加了集群恢复服务的时间(集群在选举阶段不可服务),并且增加了协议的复杂度。Raft解决的办法是,在选主逻辑中,对能够成为主的节点加以限制,确保选出的节点已定包含了集群已经提交的所有日志。如果新选出的主节点已经包含了集群所有提交的日志,那就不需要从和其他节点比对数据了。简化了流程,缩短了集群恢复服务的时间。

etcd应用场景

=======================================================================

  • etcd应用场景很多,主要的有以下六种:

  • 服务发现

  • 消息发布与订阅(配置中心)

  • 负载均衡(集群管理)

  • 分布式锁、分布式队列

  • 集群监控

  • LEADER竞选。

服务发现


  • 服务发现要解决的也是分布式系统中最常见的问题之一,即在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口,并且通过名字就可以查找和连接。要解决服务发现的问题,需要具备以下三点:

  • 1.一个强一致性、高可用的服务存储目录。基于 Raft 算法的 etcd 天生就是这样一个强一致性高可用的服务存储目录。

  • 2.一种注册服务和监控服务健康状态的机制。用户可以在 etcd 中注册服务,并且对注册的服务设置key TTL,定时保持服务的心跳以达到监控健康状态的效果。

  • 3.一种查找和连接服务的机制。通过在 etcd 指定的主题下注册的服务也能在对应的主题下查

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值