备忘

背景

去年11月份研究了一下开源的datadog agent代码(7.32.1), 整理了一篇文档。

1 日志数据流转

1. tailer首先从log文件读取，将读取的内容源源不断地发送到 decoder的 input channel中
2. decoder 从自身的input channel读取数据 ，判断数据是否需要截断，将数据写入line parser的 input channel
3. line parser从自身的input channel读取数据，解析内容、status、时间戳等，写入line handler的 input channel
4. line handler从自身的input channel 读取数据，去除空格，发送到自身的output channel
5. tailer forwardMessage 从decoder的output channel（与line handler共享）读取数据，添加tag后， 发送给pipeline的 input channel
6. processor 从自身的input channel（pipe line的input channel）读取数据，encode后（比如encode为json/pb格式），发送到sender的input channel
7. sender 从input channel读取数据，最后又将message写入pipeline的output channle
8. sender将message的content发送给datadog 后台，发送时默认不压缩传输，http支持gzip压缩传输，tcp不支持压缩。
9. pipeline的output channel初始传入的是auditor的 input channel。 auditor从input channel 读取数据，写入内存 ，定时器从buffer刷入磁盘，另外一个定时器定期清理内存过期数据

一 背景描述

线上最大的集群增长即将达到社区的最大节点数，团队比较关注, 按照当前线上的使用方式单个集群能支撑到多大规模， 因此安排了这次测试。

二 测试版本及配置信息

kubernetes 1.12.4

硬件配置：

集群由294台M10构成, 单位：台

三 模型简述：

1 社区认为每个node上30个pod是正常负载，因此饱和性测试最终生成8k*30=24w 个pod。 记录24w pod生成时间，计算出调度的吞吐量。这个过程主要是用用于模拟集群大面积故障 ，恢复全部服务的时间。 =》 Scheduling throughput

问题描述

值班同学反馈线上一台centos7的物理机container层kmem打开了 kubepods层kmem是关闭的。

问题排查

kubelet如果是打开了kmem，从kubepods层就能看到slabinfo的内容，因此排除是kubelet版本低的问题。继续排查18版本的docker-runc代码部分，发现runc中默认是打开kmem的。

13和18版本runc关于kmem部分的代码对比

docker13 runc	docker18 runc