Etcd 构建高可用Etcd集群

网友投稿 696 2022-11-30

Etcd 构建高可用Etcd集群

Etcd 构建高可用Etcd集群

在生产线上面,虽然etcd使用起来很简单,只需要put get watch这几条命令就可以将整个数据让它流转起来,在生产线上面etcd还有很多很多的问题,包括第一安全如何保证,第二高可用的etcd集群如何构建,第三数据如何备份,这些都和整个集群安全性息息相关。

Etcd成员重要参数

ETCD_NAME:节点名称,集群中唯一

参数有几类,第一类就是核心参数,最基本的参数,和成员相关,每个etcd成员都有它自己的名字,默认是default,所以去建Etcd集群的时候,什么参数都不加的时候,这个Etcd成员叫做default。

ETCD_NAME="etcd-1"ETCD_NAME="etcd-2"ETCD_NAME="etcd-3"

ETCD_DATA_DIR:数据目录

etcd最终的数据落盘,etcd成员member的名字.etcd。

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

ETCD_LISTEN_PEER_URLS:集群通信监听地址 ETCD_LISTEN_CLIENT_URLS:客户端访问监听地址

支持两类的url,一类是peer url,因为etcd是集群,member和member之间的通信是走peer url的,客户端发送到etcd server的这种请求是走client url的,所以这两类不同的请求,不同类型的数据,它是用不同的端口提供数据的。

为了更好的保障说peer之间,可能它的优先级更加高,将来做网络调优的时候可以针对peer的端口去做网络层面的数据保证。

所以它们是隔离的,client走client,peer走peer。

ETCD_INITIAL_ADVERTISE_PEER_URLS="ETCD_ADVERTISE_CLIENT_URLS:客户端通告地址

对外宣告的地址是什么

Etcd安全相关的参数

既然peer和client是两个端口,每一个端口都需要做安全保证的,etcd最常用的一种安全保障方式是mutal TLS,就是双向的TLS,一个是客户端要访问server的时候,要验证server端,一个是server端要验证你的客户端。

对应的每个端口上面都有相关的这种TLS配置参数,比如cert是什么,key是什么,client crl是什么。

要去访问一个TLS的etcd,那么就要带着它的key server 以及ca去访问。

--cert-file=/opt/etcd/ssl/server.pem \--key-file=/opt/etcd/ssl/server-key.pem \--peer-cert-file=/opt/etcd/ssl/server.pem \--peer-key-file=/opt/etcd/ssl/server-key.pem \--trusted-ca-file=/opt/etcd/ssl/ca.pem \--peer-trusted-ca-file=/opt/etcd/ssl/ca.pem \

有了上面的参数就可以将集群搭建起来了。

灾备

有了上面这些参数就可以将集群搭建起来,搭建起来的集群是个多member的,这些member会在不同的节点上面,一个节点坏了,还有其他节点保存着数据,所以数据不会丢失。

通过这种情况,数据大部分是安全的,但是会有一些极端的情况,如果所有的member一起消失了,那么数据就丢掉了,所以这是不可忍受的。

比如etcd是以pod的方式跑起来的,pod本身它的数据盘有没有mount到外面来,这个pod因为某些原因导致它写入的数据太多,被驱逐了,驱逐之后这些数据就全部丢掉了,etcd所有的pod被驱逐,数据丢掉了。

数据丢了会意味着非常严重的问题,etcd保存了kubernetes集群当中所有重要的信息。

比如calico cni插件,他可以有自己的etcd,它会保存当前集群所有IP分配的信息,如果这个信息丢了,假设这个集群你跑了10W个Pod,这个集群10W个pod它IP分配情况是什么样的已经全部消失了,当你去启动新pod的时候,这个pod的IP在别的地方分配过你根本不知道,很可能是这个IP被重复分配,分配到另外一个节点或者当前节点pod上面。

它导致的问题非常严重,整个集群的IP就混乱了,那么可能就会发生两个pod抢占一个IP的情况,那么当用户来访问一个服务的时候,本来是要访问这个服务的,结果跳到另外一个服务上面去了,这是非常严重的问题,这种结果是谁也承受不了的。

所以etcd的数据安全性非常的重要,除了多副本保证数据安全性之外,我们还要经常性的去做备份。

备份的好处是即使实例掉了,那么还可以从备份还原,虽然时效性没有那么强,损失的数据从备份产生的时间点到当前的集群的时间点,如果备份频度越高,那么丢失的数据就越少。

etcd本身支持通过snapshot命令来为集群的数据创建快照,同时支持restore的命令将快照里面的信息回放出来,将数据恢复。

如何去构建一个kubernetes高可用集群,其实最后还是要看etcd的高可用怎么做,apiserver的高可用怎么做,control manager和scheduel调度器怎么做。

上面就是etcd的高可用方面的管理。

Etcd容量管理、碎片清理

容量管理

Etcd它给了一些建议,单个对象不超过1.5M,当你数据很大的时候,它的同步开销和内存快照的开销都非常大,会使得整个etcd的性能显著下降,所以建议对象不要太大。

etcd默认容量是2G,它不建议超过8G,一般生产系统就会设置为8G。

清理磁盘碎片 defrag

上面就是设置etcd存储大小为16M,然后不停往里面写数据,超过容量报错如下,集群被我写爆了,超出配额之后就没有办法写入数据了

现在处于alarm状态,出事了,没有空间了,对于alarm状态的集群来说,任何的写操作就不能成功了。

可以通过defrag清理硬盘,这个时候其实可以清理出一些硬盘空间,但是alarm的no space还在的,这个时候去写还是一样会报错。

所以要先去解除alarm,然后再去写入才能成功。 如果去做etcd的运维一定会出现这种情况,因为数据的写入导致磁盘的暴涨,导致db被撑爆了,这个时候会出现alarm状态,做了数据的清理如果想要继续写数据,要去先禁用一下alarm,这样才能数据的写入。

那么defrag是清理磁盘碎片,磁盘碎片清理还要其他操作,比如有compact命令,etcd是一个多版本的管理系统,在bolt db里面,它的所有的key都是version信息,所以它会有很多历史版本的信息,但是很多时候历史版本信息可能用不上了,这个时候我们希望它做一些压缩,那么它支持compact命令,让你指定reversion的版本,那么会将之前所有版本清除掉,这样节省空间。

其次defrag做磁盘碎片的整理,很多碎片导致磁盘的利用率不高,那么defrag一下就ok了。

etcd后面版本其实自动支持了compact,之前需要手动,在老版本里面etcd是非常需要运维的,经常会出现硬盘又被撑爆了,那么我们要去上线查原因,去从compcat,后面etcd支持自动的去做compcat这样一个操作。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Etcd 基于Raft的一致性保证
下一篇:springboot 传参校验@Valid及对其的异常捕获方式
相关文章

 发表评论

暂时没有评论,来抢沙发吧~