总结:K8s之Etcd

一、介绍

简介

Etcd是CoreOS基于Raft协议开发的分布式key-value存储,可用于服务发现、共享配置以及一致性保障(如数据库选主、分布式锁等)。

  • 如,Etcd也可以作为微服务的注册中心,比如SpringCloud也基于ETCD实现了注册中心功能,可以替代earka,具体参考:Spring Cloud Etcd

在分布式系统中,如何管理节点间的状态一直是一个难题,etcd是专门为集群环境的服务发现和注册而涉及,它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能,可以方便的跟踪并管理集群节点的状态。

Etcd被形容为Kubernetes集群的大脑,是 Kubernetes的关键组件,因为它存储了集群的整个状态:其配置,规格以及运行中的工作负载的状态。

在Kubernetes世界中,etcd用作服务发现的后端,并存储集群的状态及其配置。

Etcd被部署为一个集群,几个节点的通信由Raft算法处理。在生产环境中,集群包含奇数个节点,并且至少需要三个。

特点

etcd作为一个受到ZooKeeper与doozer启发而催生的项目,除了拥有与之类似的功能外,更专注于以下四点。

  1. 简单:基于HTTP+JSON的API让你用curl就可以轻松使用。
  2. 安全:可选SSL客户认证机制。
  3. 快速:每个实例每秒支持一千次写操作。
  4. 可信:使用Raft算法充分实现了分布式。

        简单:curl可访问的用户的API(HTTP + JSON)

        安全:可选的SSL客户端证书认证

        快速:单实例每秒1000次写操作

        可靠:使用Raft算法保证一致性

主要功能

        1. 基本的key-value存储

        2. 监听机制

        3. key的过期及续约机制, 用于监控和服务发现

        4. 原子Compare And Swap和Compare And Delete, 用于分布式锁和leader选举

架构

基础模块介绍

client 层: 包含 client v2 和 v3 两个大版本 API 客户端
API 网络层:主要包含 client 访问 server 和 server 节点之间的通信协议。client 访问 server 分为两个版本:v2 API 采用 HTTP/1.x 协议,v3 API 采用 gRPC 协议。server 之间的通信:是指节点间通过 Raft 算法实现数据复制和 Leader 选举等功能时使用的 HTTP 协议
Raft 算法层:实现了 Leader 选举、日志复制、ReadIndex 等核心算法特性,用于保障 etcd 多节点间的数据一致性、提升服务可用性等,是 etcd 的基石和亮点
功能逻辑层:etcd 核心特性实现层。如典型的 KVServer 模块、MVCC 模块、Auth 鉴权模块、Lease 租约模块、Compactor 压缩模块等,其中 MVCC 模块主要有 treeIndex 模块和 boltdb 模块组成
存储层:包含预写日志 WAL 模块、快照 Snapshot 模块、 boltdb 模块,其中 WAL 可保障 etcd crash 后数据不丢失,boltdb 则保存了集群元数据和用户写入的数据。

数据写入流程

client 发起一个更新 hello 为 world 请求后

若 Leader 收到写请求,它会将此请求持久化到 WAL 日志,并广播给各个节点

a. 若一半以上节点持久化成功,则该请求对应的日志条目被标识为已提交

b. 之后,etcdserver 模块异步从 Raft 模块获取已提交的日志条目,应用到状态机(boltdb等)

参考下图:

关于 etcd

本文的主角是 etcd。名称 “etcd” 源自两个想法,即 unix “/etc” 文件夹 和 “d” 分布式系统。“/etc” 文件夹是用于存储单个系统的配置数据的位置,而 etcd 用于存储大规模分布式的配置信息。因此,分配了 “d” 的 “/etc” 就是 “etcd”。

etcd 被设计为大型分布式系统的通用基板。这些大型系统需要避免脑裂问题,并且愿意牺牲可用性来实现此目的。 etcd 以一致且容错的方式存储元数据。 etcd 集群旨在提供具有稳定性、可靠性、可伸缩性和性能的键值存储。

分布式系统将 etcd 用作配置管理、服务发现和协调分布式工作的一致键值存储组件。许多组织在生产系统上使用 etcd,例如容器调度程序、服务发现服务和分布式数据存储。使用 etcd 的常见分布式模式包括领导者选举、分布式锁和监视机器活动状态等。

脑裂

即两个机房网络中断,导致每个机房都会选出自己的leader。

解决方案:引入“过半概念”,投票选举,只有经过过半数的同意票才能够被选举为leader。那么网络故障致使的分区问题解决了,可是它的限制也很明显就是若是出现过半的机器宕机,会致使整个集群没法正常提供服务数

与 ZooKeeper

ZooKeeper 解决了与 etcd 相同的问题:分布式系统协调和元数据存储。但是, etcd 踩在前人的肩膀上,其参考了 ZooKeeper 的设计和实现经验。从 Zookeeper 汲取的经验教训无疑为 etcd 的设计提供了支撑,从而帮助其支持 Kubernetes 等大型系统。对 Zookeeper 进行的 etcd 改进包括:

  • 动态重新配置集群成员
  • 高负载下稳定的读写
  • 多版本并发控制数据模型
  • 可靠的键值监控
  • 租期原语将 session 中的连接解耦
  • 用于分布式共享锁的 API

此外,etcd 开箱即用地支持多种语言和框架。Zookeeper 拥有自己的自定义Jute RPC 协议,该协议对于 Zookeeper 而言是完全唯一的,并限制了其受支持的语言绑定,而 etcd 的客户端协议则是基于 gRPC 构建的,gRP 是一种流行的 RPC 框架,具有 go,C ++,Java 等语言支持。同样,gRPC 可以通过 HTTP 序列化为 JSON,因此即使是通用命令行实用程序(例如curl)也可以与之通信。由于系统可以从多种选择中进行选择,因此它们是基于具有本机工具的 etcd 构建的,而不是基于一组固定的技术围绕 etcd 构建的。

在考虑功能,支持和稳定性时,etcd 相比于 Zookeeper,更加适合用作一致性的键值存储的组件。


二、Kubernetes 中的 Etcd

在Kubernetes集群的上下文中,etcd实例可以作为Pod部署在master节点上(这是我们将在本文中使用的示例)。

为了增加安全性和弹性,还可以将其部署为外部集群。

以下来自Heptio博客的序列图显示了在简单的Pod创建过程中涉及的组件。它很好地说明了API服务器和etcd的交互作用。

三、etcd安装

参考:etcd的安装与命令行使用-蒲公英云

我们一般需要看etcd的数据来验证自己的功能,比如Grafana Mimir中etcd替换memberlist,要验证是否替换成功,得要看下etcd中的数据,所以我们就涉及到看数据,看数据的话可以使用UI客户端,或者命令行。

找了几个UI客户端,发现要账号密码,但是我们的etcd集群需要ca证书验证,于是想试试命令行方式,etcd安装参见安装。

安装后的效果如下: 

四、etcd简化配置

1、获取etcd成员列表

etcdctl --endpoints=$ENDPOINTS --ca-file=/data/weiwei/helm-ww/helm-mimir/etcd/ca.pem --cert-file=/data/weiwei/helm-ww/helm-mimir/etcd/client.pem --key-file=/data/weiwei/helm-ww/helm-mimir/etcd/client-key.pem member list

 奇怪,后来上面的命令又提示Error: unknown flag: --ca-file

改了下命令:etcdctl --endpoints=$ENDPOINTS --cacert=/data/weiwei/helm-ww/helm-mimir/etcd/ca.pem --cert=/data/weiwei/helm-ww/helm-mimir/etcd/client.pem --key=/data/weiwei/helm-ww/helm-mimir/etcd/client-key.pem member list

 上面的命令每次输入太复杂了,配置个别名:alias

 etcdctl member list:

五、命令

参考:etcdctl常用指令说明(v3版本)_etcdctl v3_公众号-测试生财的博客-CSDN博客

1、获取etcd成员列表

  •  etcdctl member list

2、向etcd中写入kv

  • etcdctl put key value
  • 例:etcdctl put auth 'weiwei'

 3、从etcd查询数据

#精确查询某个key:etcdctl get auth

#模糊查询匹配到前缀为a的数据:etcdctl get --prefix a


 

模糊查询匹配到前缀为a的key(不返回value):etcdctl --prefix --keys-only=true get a  

查所有的key:etcdctl get "" --prefix --keys-only 

etcdctl命令老是有问题,于是我重新安装了和线上版本一致的客户端版本:

etcdctl version

etcdctl get "" --prefix --keys-only:

计算etcd中key对应的value的大小:echo -n $(etcdctl get collectors/compactor) | wc -c

 查看etcd各个节点的资源使用情况:etcdctl endpoint status

查看etcd各个节点的资源使用情况:etcdctl endpoint status --write-out=table

参考:


etcd 与 Zookeeper、Consul 等其它 kv 组件的对比

etcd的安装与命令行使用-蒲公英云

  • 6
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 基于Kubernetes(简称k8s)的平台技术架构主要由以下几个关键组件组成: 1. Master:负责整个平台的控制和管理,包括监控、调度、扩展等功能。Master节点通常由三个组件组成:API服务器、调度器和控制器管理器。 2. Node:也称为工作节点,负责运行应用程序的容器。节点上的Kubelet服务负责与Master节点通信并监控节点的状态。每个节点上通常还运行着一个容器运行时,如Docker,用于创建和管理容器。 3. Pod:是k8s中的最小调度单位,可以包含一个或多个容器。Pod中的容器共享网络和存储资源,可以相互之间进行通信和共享数据。 4. 控制器:负责处理平台的自愈和自动伸缩能力。比如,ReplicationController可确保指定数量的Pod副本在任何时候都处于运行状态,而Deployment则可以进行滚动升级和回滚。 5. 服务发现和负载均衡:k8s可以自动为Pod提供稳定的网络访问地址,这些地址被封装到服务(Service)对象中。服务可以通过标签(Label)选择器将请求转发到一个或多个后端Pod实例,从而提供负载均衡的功能。 6. 存储管理:k8s提供了多种存储管理方式,如主机路径挂载、共享存储(NFS)、云存储(AWS EBS、Azure Disk等)等,以满足应用程序对持久性存储的需求。 7. 网络管理:k8s可以创建和管理虚拟网络(Virtual Network),使得不同节点上的Pod可以互相通信。此外,还可以通过网络插件(如Calico、Flannel等)实现跨主机的容器网络互联。 基于k8s的平台技术架构通过将应用程序容器化,并提供了一系列功能和工具,使得应用程序的部署、扩展和管理变得更加简单和高效。不仅如此,k8s的开源生态系统还允许第三方开发者开发丰富的插件和扩展,以满足不同场景和需求的应用程序部署和管理需求。 ### 回答2: 基于Kubernetes(简称K8s)的平台技术架构是一种用于管理容器化应用程序的开源容器编排平台。K8s的技术架构主要包括控制节点、工作节点、存储和网络等组件。 在K8s技术架构中,控制节点是整个系统的核心,负责管理和协调整个集群。它包含了多个核心组件,如API Server、Controller Manager、Scheduler等。API Server提供了与外部用户和其他组件交互的接口,Controller Manager负责监控系统状态并做出相应的调整,Scheduler用于调度应用程序到工作节点上。 工作节点是集群中的工作单元,负责运行容器化应用程序。每个工作节点上运行着一个容器运行时(如Docker),同时还有Kubelet进程和Kube-proxy进程。Kubelet是一个代理程序,与控制节点进行通信,负责管理容器的生命周期、资源分配和监控等任务。Kube-proxy负责处理集群内部的网络通信,实现服务的负载均衡和容器的访问控制等功能。 存储是K8s中另一个重要的组件,用于持久化存储应用程序的数据。K8s提供了多种存储解决方案,如本地存储、网络存储和云存储等。用户可以根据应用程序的需要选择适合的存储卷,并通过K8s的存储管理器进行管理。 网络是K8s中连接各个组件的重要环节,负责实现容器之间的通信和服务的访问。K8s提供了多种网络插件,如Flannel、Calico和Weave等,用于实现集群内部的网络互通和外部的网络访问。 总结来说,基于K8s的平台技术架构包括控制节点、工作节点、存储和网络等组件。通过这些组件的协作与配合,K8s能够有效地管理和运行容器化应用程序,实现自动化的部署、扩缩容、负载均衡和故障恢复等功能。 ### 回答3: k8s是一种容器编排平台,为开发者提供了一种简单、高效、可扩展的方式来管理和部署容器化应用程序。基于k8s的平台技术架构主要包括以下几个关键组件: 1. 控制平面(Control Plane):控制平面由一组核心组件组成,负责管理整个kubernetes集群的状态和配置信息。这些核心组件包括API服务器、调度器、控制器管理器和etcd等。API服务器是k8s系统的后端服务,用于管理和接收来自用户和其他组件的请求。调度器负责根据资源需求和约束条件选择将容器调度到集群中的节点。控制器管理器负责监视集群状态变化,并执行相应的操作。而etcd是一个分布式键值存储系统,用于存储集群的配置信息。 2. 节点(Node):节点是实际运行工作负载的主机或虚拟机。每个节点上运行着一个kubelet进程,它是节点上与控制平面通信的代理。kubelet负责管理和监控节点上的容器,并与API服务器通信以接收指令。另外,节点上还运行着kube-proxy,用于实现k8s服务的负载均衡和网络代理。 3. 容器化应用程序:k8s是为容器化应用程序设计的,它提供了一种统一的部署、扩展和管理的方式。开发者可以通过定义一个或多个容器镜像,并将其封装到一个Pod中来描述应用程序的组件。Pod是最小的部署单元,可以包含一个或多个容器。k8s通过创建和管理Pod,保证应用程序的运行和可伸缩性。 4. 网络和存储:k8s提供了可插拔的网络和存储插件,以适应不同的环境和需求。网络插件负责为Pod提供网络连接,使得它们可以互相通信。存储插件则为Pod提供持久化存储,以便应用程序可以存储和访问数据。 基于k8s的平台技术架构能够帮助开发者轻松地构建、部署和管理容器化应用程序,提高开发效率和系统可用性。通过使用k8s的自动化管理和弹性伸缩功能,可以实现高可用性、可扩展性和容错性,从而满足不断变化的业务需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值