Kubernetes Etcd不可用日志:NOSPACE 的问题修复

这篇具有很好参考价值的文章主要介绍了Kubernetes Etcd不可用日志:NOSPACE 的问题修复。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

        两套k8s集群同一天同时出现etcd集群空间超过配额,kubectl get cs时发现所有的etcd均返回503报错,查看etcd的告警发现有NO SPACE的信息且 etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} endpoint status 中的DB SIZE大于2GiB。

        版本信息

  • kubernetes版本:v1.17.0

  • etcd版本:3.3.10,运行方式为docker容器

        解决步骤

注意:修复会导致所有节点Not Ready,需重启各个节点的kubelet

        1、将API版本调整为3

$ export ETCDCTL_API=3

        2、声明变量ETCD_ENDPOINT

export ETCD_ENDPOINT=(https://127.0.0.1:2379)
export ETCD_CAFILE=(/etc/kubernetes/pki/etcd/ca.crt)
export ETCD_CERTFILE=(/etc/kubernetes/pki/etcd/server.crt)
export ETCD_KEYFILE=(/etc/kubernetes/pki/etcd/server.key)

        如果不清楚etcd证书存放的位置可以使用ps命令查看,当然endpoint也可以用这种方法

$ ps -ef | grep -v grep | grep apiserver |sed 's/ /\n/g' | grep etcd
--etcd-cafile=/etc/ssl/etcd/ssl/ca.pem
--etcd-certfile=/etc/ssl/etcd/ssl/node-master-1.pem
--etcd-keyfile=/etc/ssl/etcd/ssl/node-master-1-key.pem
--etcd-servers=https://172.16.200.101:2379,https://172.16.200.102:2379,https://172.16.200.103:2379
--storage-backend=etcd3

        3、备份etcd

$ etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} \
snapshot save /var/lib/etcd/my-snapshot.db

        4、获取当前的修订编号,选取需要截断的历史

$ rev=$(etcdctl --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} endpoint status --write-out="json" |  \
egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*'| awk 'NR==1{print $1}')

        5、按第四步得到的编号进行压缩

$ etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} compact $rev 

        6、释放物理空间

$ etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE}  defrag

此步骤最好将endpoints列表中的节点拆开依次执行,否则容易引起集群震荡

        7、解除告警

$ etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} alarm disarm 

此命令可能需执行两次,确保etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} alarm list再无输出

        8、重启kubelet

        经过一段时候后,如果发现所有节点都是Not Ready状态,只需要将每个节点的kubelet重启即可

$ for node in `kubectl get node --no-headers | awk '{print $1}' | xargs`;do ssh ${node} 'systemctl restart kubelet';done

        9、观察一段时间的DB SIZE,确保无大幅度增长

$ etcdctl --endpoints=${ETCD_ENDPOINT} --cert=${ETCD_CERTFILE} --key=${ETCD_KEYFILE} --cacert=${ETCD_CAFILE} endpoints status

参考:压缩完DB SIZE是30MiB,一段时间涨到132MiB后持续不动

        为什么会超过限值?

        令我感到十分的诧异的是出问题的两套集群分别是30个和33个节点,还有其他节点数更多的集群(48个节点)的etcd不仅是正常的,并且etcd的DB SIZE仅为143MiB,连一半都没到。同时在出现问题两套集群进行完一次修复后,第二天下午又出现etcd空间满的情况。这使我不得不探究下问题发生的原因。

        自动压缩机制

        关于自动压缩机制,官方说为了防止数据大量存入etcd导致性能下降并最终导致空间耗尽,etcd会周期性的将历史的数据进行一次压缩操作。压缩完成后指定revision版本之前的数据都将变得不可访问,同时压缩过的空间将会给新键的存放留出空间。那么这个自动压缩的周期是多少呢?

        由于我这里是3.3.x版本的列子,所以仅阐述3.3.x版本的自动压缩。自动压缩参数--auto-compaction-mode=periodic --auto-compaction-retention=30m表示每30分钟压缩一次,并且每次留存30分钟的数据量。假设现在的revision是7617,30分钟后revision编号是14221,那么压缩后revision编号为7617之前存放的键将不能访问。那么出现问题的etcd默认配置是什么呢?

$ cat /etc/etcd.env 
# Environment file for etcd v3.3.10
...
ETCD_AUTO_COMPACTION_RETENTION=8
...

        这个是默认的配置,保留8小时的数据量,同时压缩模式在未指定是就是periodic,即周期压缩。

--auto-compaction-mode

- Interpret 'auto-compaction-retention' one of: 'periodic', 'revision'. 'periodic' for duration based retention, defaulting to hours if no time unit is provided (e.g. '5m'). 'revision' for revision number based retention.-
- default: periodic
- env variable: ETCD_AUTO_COMPACTION_MODE

但是:不同于不满1小时的数据保留量是按照auto-compaction-retention的配置周期进行压缩。当保留的数据量大于1小时,是按照1h/次的压缩频率进行的。即保留量与压缩频率的关系如下:

if ( "--auto-compaction-retention" < 1h ):

​ 压缩频率 == 1次/"--auto-compaction-retention"

else:

​ 压缩频率 == 1次/h

        即说明出现问题的etcd默认的配置是:每1小时进行一次压缩,并且保留8个小时的数据量,同时最大空间是默认的2GiB。也就是说,如果8个小时的数据量超过了2GiB,就会引发etcd告警。那为什么唯独这两个集群有问题?后来我才发现这两套集群都是测试环境,测试环境嘛,总是会有大量的数据会写入到etcd集群,并且如果不同的业务组同时测试应用会引起etcd频繁的执行创建操作,由于etcd每小时才进行一次压缩,如果1个小时存入的数据过多etcd就会来不及压缩。久而久之,就会到达限额引发告警。反观节点数更多的生产环境,由于很少进行创建操作,DB SIZE自然会很小。理解了这个就明白了如果避免etcd空间告警了。只需etcd.env中修改如下参数并且重启etcd即可:

#更新保留时间缩短为4小时
ETCD_AUTO_COMPACTION_RETENTION=4
#添加etcd最大空间为8GiB的配置
ETCD_QUOTA_BACKEND_BYTES=8589934592

非docker启动的etcd集群参数如下:
--quota-backend-bytes=8589934592  --auto-compaction-retention=4

        再观察了几天之后,这两套etcd集群再没有发生过空间超过的问题。

        KeySpace与存储空间

        在解决步骤的第6步,会执行defrag命令,这是用来释放碎片文件的。碎片文件是etcd进行compaction操作后历史的数据,这部分的空间是可以被用来存放新键的。所以在进行完compaction操作后是没有必要进行defrag的。只有当etcd的空间满了进行释放空间的操作时才需要进行defrag操作。

        如何查看etcd空间的实际使用量?

        通过etcdctl命令查看的DB SIZE是etcd历史最大的数据量大小,不是目前的数据量。etcd对外暴露了mertics提供监控信息,其中名为etcd_mvcc_db_total_size_in_use_in_bytes的值即是目前数据量的大小。查询方法可使用下面的命令:文章来源地址https://www.toymoban.com/news/detail-719616.html

curl -s --cacert ${ETCD_CA_FILE} --cert ${ETCD_CERT_FILE} --key ${ETCD_KEY_FILE} `echo ${ETCD_ENDPOINTS}   \
| awk -F, '{print $1}'`/metrics -o-| egrep ^etcd_mvcc_db_total_size_in_use_in_bytes | awk '{print $2}' | awk '{printf("%.2fMiB",$0/1024/1024)}'

到了这里,关于Kubernetes Etcd不可用日志:NOSPACE 的问题修复的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 二进制搭建Kubernetes集群(一)——部署etcd集群和单master

    注意:生产环境中,etcd集群和master、node节点都应该部署在不同的机器上,此处为了实验方便,将三台etcd节点分别部署在了master和node节点上了 k8s集群master01:192.168.126.27    kube-apiserver kube-controller-manager kube-scheduler etcd k8s集群master02:192.168.80.21 k8s集群node01:192.168.80.11    

    2024年02月10日
    浏览(48)
  • 【kubernetes系列】kubernetes之基础组件高可用方案

    从前面的基础章节了解到,kubernetes的mastere节点基础组件大致包括kube-apiserver、kube-controller-manager、kube-scheduler,还有一个重要的数据存储服务etcd。这些主件作为master节点的服务相当重要,很多时候我们都需要保证其高可用。下面将分享在实际工作中的一些常见做法。 在使用私

    2024年02月16日
    浏览(34)
  • kubernetes--kubernetes审计日志(api访问日志)

    目录 一、审计日志介绍: 二、事件和阶段: 三、Kubernetes审计日志: 四、审计日志的启用: 五、收集审计日志方案:        在Kubernetes集群中,API Server的审计日志记录了哪些用户、哪些服务请求操作集群资源,并且可以编写不通规则,控制忽略、存储的操作日志。    

    2024年02月10日
    浏览(43)
  • 【kubernetes系列】kubernetes之使用kubeadm搭建高可用集群

    目前来说,kubernetes集群搭建的方式很多,选择一个稳定的适合自己的很重要。目前使用kubeadm方式搭建k8s集群还是很常见的,使用kubeadm搭建可以很简单差不多两条命令就行,也可以稍微复杂一点做一些基础优化,本文将分享一下使用kubeadm搭建集群并做了一定的优化。 本环境

    2024年02月15日
    浏览(40)
  • 云原生|kubernetes|centos7下的kubeadm部署的集群内在线部署kubesphere(外部etcd)

    本文将主要就在centos7操作系统下已有的一个利用kubeadm部署的集群内在线安装kubesphere做一个介绍,该kubernetes集群是使用的etcd外部集群。 kubernetes集群的搭建本文不做过多介绍,具体的搭建流程见我的博客: 云原生|kubernetes|kubeadm部署高可用集群(一)使用外部etcd集群_kubeadm

    2024年02月11日
    浏览(44)
  • Kubernetes高可用集群二进制部署(六)Kubernetes集群节点添加

    Kubernetes概述 使用kubeadm快速部署一个k8s集群 Kubernetes高可用集群二进制部署(一)主机准备和负载均衡器安装 Kubernetes高可用集群二进制部署(二)ETCD集群部署 Kubernetes高可用集群二进制部署(三)部署api-server Kubernetes高可用集群二进制部署(四)部署kubectl和kube-controller-man

    2024年02月14日
    浏览(47)
  • Kubernetes 企业级高可用部署

    单master节点的可靠性不高,并不适合实际的生产环境。Kubernetes 高可用集群是保证 Master 节点中 API Server 服务的高可用。API Server 提供了 Kubernetes 各类资源对象增删改查的唯一访问入口,是整个 Kubernetes 系统的数据总线和数据中心。采用负载均衡(Load Balance)连接多个 Master 节

    2024年02月12日
    浏览(49)
  • Kubernetes 集群的异常处理手段,包括集群自愈、集群监控、日志收集、集群规模扩容、节点问题处理、Pod问题定位、网络故障诊断、应用性能瓶颈分析、应用访问失效问题排查等方面知识

    作者:禅与计算机程序设计艺术 随着容器技术的普及和应用,容器集群已经成为云计算领域中一个重要的基础设施,用来提供快速、可扩展、高可用和弹性的服务。Kubernetes(简称K8s)是最具代表性的开源容器编排引擎之一,通过自动化部署、管理和调度容器ized application,极

    2024年02月07日
    浏览(41)
  • 安装kubernetes高可用集群(v1.26)

    kubernetes的master是需要配置高可用集群的,当一台master出问题了之后另外一台master仍然是可以继续工作的。比如下图 不管是worker还是client,只要把请求发送到LB负载均衡器,然后LB会把请求在master1和master2之间进行转发。这里只要有一个master能够正常工作,整个kubernetes集群就会

    2024年02月03日
    浏览(45)
  • 使用nginx搭建kubernetes高可用集群

    本文使用 nginx 搭建 kubernetes 高可用集群。 服务器规划(本实验采用虚拟机): ip hostname 说明 192.168.43.200 master master 192.168.43.201 slave1 slave 192.168.43.202 slave2 slave 192.168.43.203 master2 master 192.168.43.165 nginx nginx主机 2.1 关闭防火墙 2.2 关闭 selinux 2.3 关闭 swap 2.4 设置主机名称 使用命令 h

    2024年02月10日
    浏览(66)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包