前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >生产K8s Rsyslogd内存优化

生产K8s Rsyslogd内存优化

作者头像
保持热爱奔赴山海
发布2022-01-11 13:31:50
8770
发布2022-01-11 13:31:50
举报
文章被收录于专栏:DevOps数据库相关

最近发现K8s机器经常有内存告警,上去抽了几台ECS 看了下都发现了rsyslogd占用大量内存的情况出现。

如下图:

生产K8s Rsyslogd内存优化_K8s
生产K8s Rsyslogd内存优化_K8s

根因分析

k8s宿主机上,/var/log/messages有几个G的日志,发现rsyslog把Journal的log都进行的输出和汇总。 当容器越多是,log也就会也多,内存占用也就越多。同时也可能导致systemd-journald内存占用过高。

因此我们最好优化下journald和rsyslog的参数,将宝贵的内存资源留给业务服务去使用。

下图是 journalctl -xe 执行的结果示例:

生产K8s Rsyslogd内存优化_rsyslogd_02
生产K8s Rsyslogd内存优化_rsyslogd_02

修改方法

代码语言:javascript
复制
# 1 备份下原先配置文件
cp /etc/systemd/journald.conf  /root/
cp /lib/systemd/system/rsyslog.service  /root/

# 2 修改journald服务
cat /etc/systemd/journald.conf 改动后的3行如下: 
[Journal]
Storage=persistent
SystemMaxUse=1024M
ForwardToSyslog=no

# 确保journal的日志路径存在(通常都是已存在的)
mkdir -pv /var/log/journal/

# 重启下服务
systemctl restart systemd-journald  

# 3 2 修改rsyslog服务
cat /lib/systemd/system/rsyslog.service 在 Service 段增加下面3行
MemoryAccounting=yes
MemoryMax=800M
MemoryLimit=800M

# 重启下服务
systemctl daemon-reload && systemctl restart rsyslog

多机器的话,推荐使用ansible-playbook分组部署,观察几天后,实现批量修改。

效果展示

生产K8s Rsyslogd内存优化_K8s_03
生产K8s Rsyslogd内存优化_K8s_03

PS: 对生产全部K8s主机rsyslogd都优化了一遍后,发现腾出了近128GB的内存,相当于又多买了一台128G的ECS。啊哈哈哈

TODO 持续部署

对于新加的k8s节点,rsyslogd和journald的配置也需要优化,我们可以做成一个巡检类的定时任务。

step1、封装一个check-deploy.sh脚本

代码语言:javascript
复制
具体逻辑:
1、将 /etc/systemd/journald.conf 和 /lib/systemd/system/rsyslog.service 做成固定的模板文件,算出md5值。
2、如果主机的2个文件md5和期望的不一致,则用check-deploy的脚本中的文件覆盖,并重启journald或rsyslog服务。

step2、定时任务平台 从cmdb中将k8s主机列表取出来,每天下发一次 check-deploy.sh 到目标K8s机器上并执行即可(这个变更对时效性要求不高)。

大致上的实现如下:

mkdir -pv /home/ansible-playbook/optimize_rsyslogd_mem

vim check-deploy.sh 如下:

代码语言:javascript
复制
#!/bin/bash
# 用于判断服务器的2个配置文件(k8s机器rsyslogd journald优化项)

FILE1="/lib/systemd/system/rsyslog.service"
FILE2="/etc/systemd/journald.conf"

RET1=$(md5sum ${FILE1} | awk -F ' ' '{print $1}')
RET2=$(md5sum ${FILE2} | awk -F ' ' '{print $1}')

# 已知的修改后2个文件md5(各位可以修改好一个后作为模板,记录下md5值即可)
# rsyslog.service 5d62063607a38c54d6a96865ba86b83d
# journald.conf   6ad3f6ad35c4ca7638aedaba17d175bc
FILE1_MD5="5d62063607a38c54d6a96865ba86b83d"
FILE2_MD5="6ad3f6ad35c4ca7638aedaba17d175bc"

RUN_LOG='/tmp/check-deploy.log'

if [ x"${RET1}" != x"${FILE1_MD5}" ] ; then
	echo "${FILE1} 校验和不同,将进行覆盖并重启进程" | tee -a ${RUN_LOG}
	/bin/cp /lib/systemd/system/rsyslog.service /root/ && /bin/cp template/rsyslog.service /lib/systemd/system/rsyslog.service
	systemctl daemon-reload && systemctl restart rsyslog

else
	echo "${FILE1} 校验和相同,操作跳过" | tee -a ${RUN_LOG}
fi

if [ x"${RET2}" != x"${FILE2_MD5}" ] ; then
	echo "${FILE2} 校验和不同,将进行覆盖并重启进程" | tee -a ${RUN_LOG}
	/bin/cp /etc/systemd/journald.conf /root/ && /bin/cp template/journald.conf /etc/systemd/journald.conf
	systemctl restart systemd-journald  
else
	echo "${FILE2} 校验和相同,操作跳过" | tee -a ${RUN_LOG}
fi

deploy.yaml 内容如下:

代码语言:javascript
复制
- name: deploy optimize_rsyslogd_mem
  hosts: all
  user: root
  gather_facts: false
  tasks:
   - name: 拷贝脚本到远程主机
     copy: src=/home/ansible-playbook/optimize_rsyslogd_mem dest=/tmp/ mode=0755
   - name: 执行脚本
     shell: cd /tmp/optimize_rsyslogd_mem && bash check-deploy.sh

UPDATE 2021/06/19

写完本blog后,再仔细看了下 /var/log/messages 里有很多报错,类似 xxxx has no PIDs. Refusing ,查了下google,问题大致原因是由于将 cgroup-driver 设置为 systemd 后引起的,导致我们的messages文件很大。这里我们可以在给rsyslogd再加点配置:

vim /etc/rsyslog.d/ignore-systemd-session-slice.conf

代码语言:javascript
复制
if ($programname == "systemd") and ($msg contains "_systemd_test_default.slice" or$msg contains "systemd-test-default-dependencies.scope") then {
  stop
}

systemctl restart rsyslog.service 重启下rsyslogd进程,可以看到messages中不再记录之前的那些报错的信息了。

参考: https://blog.espnlol.com/?p=525

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021/06/19 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 根因分析
  • 修改方法
  • 效果展示
  • TODO 持续部署
  • UPDATE 2021/06/19
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档