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

在工作中常常用 Deployment/Statefulset 部署工作负载，但是对工作负载的扩缩容却没用过，实属遗憾。
作为弹性扩缩容的重要一环应该是要补上的。
本学习笔记系列旨在梳理 Kubernetes 水平自动伸缩的整体脉络，并且从源码角度入手有的放矢的学习 Kubernetes 水平自动伸缩的实现。
在进入源码学习之前，让我们先自己动手设计一版水平自动伸缩的方案。
首先，为简化需求，这里给定条件，仅根据 cpu 或 memory 指标实现 Deployment 资源的水平自动伸缩。
针对上述需求，我们可以将水平自动伸缩功能拆成三个组件来实现：
容器的资源指标会被 cAdvisor 采集到，通过 kubelet api 暴露给用户。
采集器可以和 kubelet 交互获取容器的 cpu/memory 指标。
pod 可以运行在多个节点，意味着采集器需要和所有集群节点的 kubelet 交互以获取容器资源。
这么做的好处是简单，直接和 kubelet 交互。缺点是可能会造成网络拥塞。
解决方案可以是并发请求加随机请求，减轻同时并发请求导致网络拥塞/资源消耗等问题。
或者，采集器可以访问 kube-apiserver 获取所有节点上容器的资源指标。这种方式实际上是一种转移，把由采集器做的事转移给 kube-apiserver，kube-apiserver 作为 kubernetes 的门户，应该扁平、轻量，这种操作由 kube-apiserver 来做是不合适的。
因此，采集器需要和集群节点上的 kubelet 交互以获取容器的资源指标。
首先，采集器采集到指标应该存储在内存还是持久化存储？
采集器不是 prometheus，它的定位是采集时刻指标，不需要持久化存储。 这里指标存内存即可。
注意，采集器指标的存储和访问是解耦的。采集器定时采集指标，并对外提供服务，用户可通过 api 获取当前时刻的指标。
在 问题2 中采集的指标存储在内存中，那么采集器的高可用是如何实现呢？
如果基于 lease leader 来实现一主多从，那么主挂掉到从采集数据并提供服务是有一段时间的。这段时间会导致采集器服务不可用，并不高可用。
解决方案是多主。假设是 2 副本，主和从都正常采集，任何一个不可用，都可以直接切到另外一个，实现了采集器的高可用。
缺点是，kubelet 要承受副本数次 api 请求，这个并发请求数量并不大，可以忽略。
这个问题看似是一个没有必要的问题，其实还真不是。
采集器采集所有 pod 的指标还是只采集水平伸缩的 pod 指标，这是有区别的。
如果要采集水平伸缩的 pod 指标，采集器就要和配置同步以确定要采集哪些 pod，这么做的好处是采集指标较少，省内存。缺点是采集器和配置耦合，不够独立。
由于节点上的 pod 是有上限的，并且采集的指标只限于 cpu/memory，这里可以采集所有 pod 的指标。
控制器需要和采集器交互获取要水平伸缩的工作负载指标，并且根据指标和配置做伸缩决策，最后触发执行器实际执行伸缩操作。
前面说了采集器是周期性采集的，比如每 15s 采集一次资源指标。如果控制器小于 15s，比如每 5s 从采集器拉取指标，那么会导致采集器还未采集，重复拉取指标的情况。
这里建议是控制器的拉取周期大于等于采集器的采集周期。
有时候工作负载可能临时抖动，并不是真的要水平伸缩，对于这样的情况，控制器该如何决策呢？
控制器可以配一个抖动边界，如果在抖动边界内则不予处理，如果超出边界则按扩缩容处理。
当然，我们可以把这个抖动边界上移到配置中，这样每个工作负载的抖动边界不一样，更加合理。
扩缩容的判断条件不一样。扩容应该要快，防止资源不足导致服务不可用。缩容应该要慢，防止工作负载被缩导致服务不可用。
比如扩容可以将窗口设为 0，意味着一旦超过抖动边界上限，则立即开始扩容。 比如缩容可以将窗口设为 2min，如果 2min 内资源持续减少，则选择 2min 内的最大值做缩容。
假设初始工作负载副本是 10，在 2min 内期望伸缩副本一直在递减，到 150s 超过递减窗口，需要缩容，这里取 2min 窗口内的最大值 9 做期望副本，工作负载将缩容到 9 个。
这么做的好处是防止缩容跨度太大导致服务不可用。
扩容要选大的，往大了扩。 缩容要选大的，往小了缩。
从采集器拿到的是瞬时值，而窗口需要记录期望副本数，需要把每次采集算的期望副本数及时间戳记录到窗口中。
可以采用环形队列来表示窗口，注意每个水平伸缩的工作负载对应一个环形队列（窗口大小可以不一样）。
我们有了工作负载的指标，也有工作负载资源的 request，那怎么确定要伸缩多少呢？
如果超过抖动边界就扩缩 1 的话，不够灵活。跟不上业务的需求，这里需要根据使用情况以及副本数做动态调整。
比如，当前工作负载副本数是 2，CPU 的平均使用率是 50%，现在两个工作负载都超过 50%（不考虑抖动边界的情况），需要扩容。如果实际使用量是 100% 和实际使用量是 60%，扩容的期望副本数是不一样的，需要算法动态调整。