kube-state-metrics 在大规模集群下的优化
当我们使用 Prometheus 来监控 Kubernetes 集群的时候， 基本属于一个必备组件，它通过 Watch APIServer 来生成资源对象的状态指标，它并不会关注单个 Kubernetes 组件的健康状况，而是关注各种资源对象的健康状态，比如 Deployment、Node、Pod、Ingress、Job、Service 等等，每种资源对象中包含了需要指标，我们可以在官方文档 https://github.com/kubernetes/kube-state-metrics/tree/main/docs 处进行查看。
要安装 KSM 也非常简单，代码仓库中就包含了对应的资源清单文件，但是在安装的时候记得要和你的 K8s 集群版本对应。
我这里的测试集群是 v1.25 版本的，所以我先切换到该分支：
该方式会以 Deployment 方式部署一个 KSM 实例：
然后只需要让 Prometheus 来发现 KSM 实例就可以了，当然有很多方式，比如可以通过添加注解来自动发现，也可以单独为 KSM 创建一个独立的 Job，如果使用的是 Prometheus Operator，也可以创建 ServiceMonitor 对象来获取 KSM 指标数据。
这种方式对于小规模集群是没太大问题的，数据量不大，可以正常提供服务，只需要保证 KSM 高可用就可以在生产环境使用了。但是对于大规模的集群来说，就非常困难了，比如我们这里有一个 8K 左右 Pod 的集群，不算特别大。
但是只通过一个 KSM 实例来提供 metrics 指标还是非常吃力的，这个时候可能大部分情况下是获取不到指标的，因为 metrics 接口里面的数据量太大了。
即使偶尔获取到了，也需要话花很长时间，要知道我们会每隔 的时间都会去访问该指标接口的，可能前面一次请求还没结束，下一次请求又发起了，要解决这个问题就得从 KSM 端入手解决，在 KSM 的启动参数中我们可以配置过滤掉一些不需要的指标标签：
可以通过 或者 参数进行过滤。但是如果即使过滤了不需要的指标或标签后指标接口数据仍然非常大又该怎么办呢？
其实我们可以想象一下，无论怎么过滤，请求一次到达 metrics 接口后的数据量都是非常大的，这个时候是不是只能对指标数据进行拆分了，可以部署多个 KSM 实例，每个实例提供一部分接口数据，是不是就可以缓解压力了，这其实就是我们常说的水平分片。为了水平分片 ，它已经实现了一些自动分片功能，它是通过以下标志进行配置的：
(从 0 开始)
分片是通过对 Kubernetes 对象的 UID 进行 MD5 哈希和对总分片数进行取模运算来完成的，每个分片决定是否由 kube-state-metrics 的相应实例处理对象。不过需要注意的是，kube-state-metrics 的所有实例，即使已经分片，也会处理所有对象的网络流量和资源消耗，而不仅仅是他们负责那部分对象，要优化这个问题，Kubernetes API 需要支持分片的 list/watch 功能。在最理想的情况下，每个分片的内存消耗将比未分片设置少 。通常，为了使 kube-state-metrics 能够迅速返回其指标给 Prometheus，需要进行内存和延迟优化。减少 kube-state-metrics 和 kube-apiserver 之间的延迟的一种方法是使用 标志运行 KSM，除了减少延迟，这个选项还将导致减少对 etcd 的负载，所以我们也是建议启用该参数的。
当然如果使用了分片模式，则最好对分片相关指标进行监控，以确保分片设置符合预期，可以用下面两个报警规则来进行报警：
由于手动去配置分片可能会出现错误，所以 KSM 也提供了自动分片的功能，可以通过 StatefulSet 方式来部署多个副本的 KSM，自动分片允许每个分片在 StatefulSet 中部署时发现其实例位置，这对于自动配置分片非常有用。所以要启用自动分片，必须通过 StatefulSet 运行 kube-state-metrics，并通过 和 标志将 pod 名称和命名空间传递给 kube-state-metrics 进程，如下所示：
使用这种部署分片的方法，当你想要通过单个 Kubernetes 资源（在这种情况下为单个 StatefulSet）管理 KSM 分片时是很有用的，而不是每个分片都有一个 Deployment，这种优势在部署大量分片时尤为显着。
当然使用自动分片的部署方式也是有缺点的，主要是来自于 StatefulSet 支持的滚动升级策略，当由 StatefulSet 管理时，一个一个地替换 pod，当 pod 先被终止后，然后再重新创建，这样的升级速度较慢，也可能会导致每个分片的短暂停机，如果在升级期间进行 Prometheus 抓取，则可能会错过 kube-state-metrics 导出的某些指标。
自动分片功能的示例清单在 目录中可以找到，可以直接通过下面的命令来部署：
上面的命令会以 StatefulSet 方式部署 2 个 KSM 实例：
可以随便查看一个 Pod 的日志：
可以看到有类型 这样的日志信息，表面自动分片成功了。我们可以去分别获取下分片的指标数据大小，并和未分片之前的进行对比，可以看到分片后的指标明显减少了，如果单个实例的指标数据还是太大，则可以增加 StatefulSet 的副本数即可。
此外我们还可以单独针对 pod 指标按照每个节点进行分片，只需要加上 和 即可，这个时候我们直接使用一个 DaemonSet 来创建 KSM 实例即可，如下所示：
对于其他的指标我们也可以使用 来单独指定部署，也可以继续使用分片的方式。总结来说就是对于大规模集群使用 kube-state-metrics 需要做很多优化：
过滤不需要的指标和标签
通过分片降低 KSM 实例压力
可以使用 DaemonSet 方式单独针对 pod 指标进行部署
当然可能也有人会问，如果自己的业务指标也超级大的情况下该怎么办呢？当然就得让业务方来做支持了，首先要明确指标数据这么大是否正常？如果需求就是如此，那么也得想办法能够支持分片。
- 发表于:
- 原文链接：https://kuaibao.qq.com/s/20230216A04EZ700?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
