kubernetes 水平自动伸缩学习笔记（二） - 胡云Troy - 博客园

上一篇笔记在介绍 kubernetes 水平自动伸缩实现前先预设了整体架构。本篇笔记将围绕 kubernetes 的采集器 Metrics Server 进行介绍。
kubernetes 采集器的架构如下图所示：
对比 kubernetes 水平自动伸缩学习笔记（一） 中我们设计的架构主要有以下区别：
本篇学习笔记基于 metrics-server release-0.6 进行介绍。
metrics-server release-0.6 有以下核心设计要点：
这两个问题可以归为一类回答，采集器作为独立的组件并不和具体业务耦合。那么它要做的就是尊重事实（而不是像 hpa controller 尊重业务）。
metrics-server 会尽可能推导出 prev/last 的资源使用率但是尊重事实。
对于第一问，如果没有采集到则不采集，不推断/重采缺失指标。 对于第二问，如果不一致则清空 prev/last 不计算该 pod 的使用率。
本节从源码角度分析 metrics-server 的工作流程。
创建定时器定时采集，采集周期默认为 15s，可配置。
这里并发采集有点意思，如果用协程分批次收集可能是一种反模式。虽然能控制协程数，但是收集的总时间延长了，并不好。当然如果超大规模集群这么并发创建协程还是有风险的。
通过 kubelet client 收集指标：
存储指标是重点，指标通过哈希表的形式存储以实现 O(1) 时间复杂度查询。查看实现如下：
收集的指标根据 node 或 pod 分开存储到内存 storage 中，代码见 这里。
从 metrics-server 的行为看，存储是尊重事实的，如果指标在 prev/last 缺失，不能构造 pre/last 区间指标的话就不存。
具体的业务逻辑由上层应用去处理，解耦业务和通用组件。
metrics-server 的性能可以参考 官网，这里就不过多介绍了。
对于 metrics-server 的调优可以从以下角度入手：