专栏
登录
serverless 虚拟节点pod监控方案设计
2023-12-13 13:44:49 31阅读
对于 Kubernetes 场景下的Pod指标，采集源为 kubelet 内置的 cAdvisor，对外暴露/metrics/cadvisor接口，用于提供容器内存、CPU、网络、文件系统等相关的指标。
在sce和ccse使用虚拟节点接入ECI实例的场景下，需要实现虚拟节点采集ECI实例的CPU、内存、网络等监控指标。同样，虚拟节点也需要提供/metrics/cadvisor接口，以支持对pod的内存、CPU、网络、文件系统等的监控。
经调研，
1）ack的虚拟节点实现了与kubelet一致的/metrics/cadvisor接口，用以对外提供容器相关指标。
实例内部监听了10250端口，并且跟虚拟节点建立了连接：
创建1个ECI pod，cadvisor数据量为110K左右，查看虚拟节点资源占用情况：
创建10个ECI pod，cadvisor数据量达到1M左右，查看虚拟节点资源占用情况:
可以看到，从1个pod到10个pod，虚拟节点内存占用只增长了4M左右。
应用场景
场景1：虚拟节点容器监控指标在ccse控制台（sce控制台）页面展示
- 策略1：ccse监控插件从arms拉取虚拟节点监控指标
- 策略2：虚拟节点提供/metrics/cadvisor接口，ccse监控插件从虚拟节点获取监控指标并展示
场景2：虚拟节点容器监控指标推送到arms
- 策略1：虚拟节点提供/metrics/cadvisor接口，ccse监控插件从虚拟节点采集指标数据并推送到arms
- 策略2：虚拟节点直接推送到arms
- 策略3：ECI实例直接推送到arms，虚拟节点不处理
场景3：prometheus采集虚拟节点容器监控指标提供给第三方
- 策略1：虚拟节点提供/metrics/cadvisor接口，供第三方采集
- 策略2：第三方从arms拉取虚拟节点监控指标
- 策略3：虚拟节点支持配置推送到第三方
场景4：虚拟节点容器监控指标提供给HPA使用
方案设计
-
方案1：虚拟节点提供/metrics/cadvisor接口（缓存）
虚拟节点采集ECI实例的容器指标数据对接的是ECI-agent中的cadvisor接口：
-
采集服务：虚拟节点定时遍历获取所有容器指标数据
-
数据处理：对获取到的容器指标数据进行填充或清理
-
数据缓存：缓存所有容器最新监控指标数据
缓存数据处理后所有容器的指标数据，只保留最新的数据
-
对外服务：对外提供/metrics/cadvisor接口，从缓存中获取监控指标数据再返回
-
数据监控：对于采集失败的容器，记录并告警（容器不正常导
采集失败的容器记录到日志中，如果超过一定时间都没采集到该容器数据，则告警到虚拟节点的监控指标中
-
致采不到数据的情况不考虑）
-
- 方案2：虚拟节点推送容器监控指标到arms
数据推送：缓存数据到达一定量后调用arms接口，或者达到定时时间间隔就调用arms接口推送数据。
数据监控：采集失败的容器记录到日志中，如果超过一定时间都没采集到该容器数据，则告警到虚拟节点的监控指标中；推送失败记录到日志中，超过一定时间内都推送失败，则告警到虚拟节点的监控指标中。
- 方案3：融合方案，虚拟节点推送容器监控指标到arms，并提供/metrics/cadvisor接口
数据推送：缓存数据到达一定量后调用arms接口，或者达到定时时间间隔就调用arms接口推送数据。
数据缓存：只缓存所有容器指定基础指标的数据，并只保留最新数据
数据监控：采集失败的容器记录到日志中，如果超过一定时间都没采集到该容器数据，则告警到虚拟节点的监控指标中；推送失败记录到日志中，超过一定时间内都推送失败，则告警到虚拟节点的监控指标中。
优劣势对比
| 方案 | 方案1：虚拟节点提供/metrics/cadvisor接口（缓存） | 方案2：虚拟节点推送容器监控指标到arms | 方案3：融合方案，虚拟节点推送容器监控指标到arms，并提供/metrics/cadvisor接口 |
|---|---|---|---|
| 存在的问题 | 1、当虚拟节点管理的pod数量增大，占用内存过高 2、数据处理过程占用内存较高 |
1、推送失败存在丢失一段时间内监控指标的风险 2、涉及ccse监控等外部插件的改动 3、数据处理过程占用内存较高 |
1、推送失败存在丢失一段时间内监控指标的风险 2、当虚拟节点管理的pod数量增大，还是会占用部分内存 3、数据处理过程占用内存较高 |
| 优势 | 1、与普通节点保持一致，业务兼容性高 2、请求即时返回，用户体验好 |
1、不需要对接其他业务，只上报到arms，业务目标明确； 2、不用缓存大量指标数据，占用内存小； |
1、与普通节点保持一致，业务兼容性高； 2、只需缓存少量指标数据，占用内存较小； 3、请求能即时返回基础指标数据，详细指标可从arms获取； |
资源消耗情况
方案1：虚拟节点提供/metrics/cadvisor接口
| pod个数 | 数据大小 | 峰值内存 | 最小内存 |
|---|---|---|---|
| 1 | 68.31KB | 11.539307 MB | 6.192055 MB |
| 100 | 6.15MB | 126.820206 MB | 41.492966 MB |
| 1000 | 61.43MB | 1504.873192 MB | 432.292625 MB |
| 2000 | 122.74MB | 3588.519409 MB | 699.981644 MB |
方案1：虚拟节点提供/metrics/cadvisor接口（优化后）
| 优化前 | 优化后 |
|---|---|
| 无协程池控制并发 | 增加协程池控制并发协程数（500） |
| 所有pod都获取到数据后再存储更新缓存 | 每个pod获取到数据之后先存储起来，再统一删除不存在的pod； |
| 缓存cadvisor返回的指标数据结构体 | 将数据处理后的数据结构体转成string再存储 |
| 处理缓存数据，对指标数据进行合并后再返回 | 调用接口直接返回缓存的string； |
| pod个数 | 数据大小 | 峰值内存 | 最小内存 | 采集耗时 |
|---|---|---|---|---|
| 1 | 68.31KB | 13.340675 MB | 7.090134 MB | 49.2864ms |
| 10 | 681.97KB | 14.679649 MB | 7.673645 MB | 158.2419ms |
| 100 | 6.82MB | 56.944633 MB | 18.985733 MB | 965.8332ms |
| 1000 | 68.20MB | 668.788277 MB | 127.175316 MB | 9.1484256s |
| 2000 | 136.40MB | 1237.441261 MB | 269.664116 MB | 16.0854393s |
| 5000 | 341MB | 4390.664368 MB | 455.211411 MB | 27.2741929s |
峰值内存占用主要是在于数据处理过程中，需要解析数据导致内存占用增大。
后续优化方向：
- 在数据处理过程中，可以分批处理数据，限制峰值内存最大不超过2G。
- 数据处理再删除不必要的数据，减小缓存数据大小。
- 考虑缓存数据只保留多长时间，需跟ccse 监控插件约定只能拉取多长时间内的数据，拉完就删。
- 不进行数据处理，获取到数据直接存储或推送。（不考虑）
- 1
- 1
- 0
-
发表评论
serverless 虚拟节点pod监控方案设计
2023-12-13 13:44:49 31阅读
对于 Kubernetes 场景下的Pod指标，采集源为 kubelet 内置的 cAdvisor，对外暴露/metrics/cadvisor接口，用于提供容器内存、CPU、网络、文件系统等相关的指标。
在sce和ccse使用虚拟节点接入ECI实例的场景下，需要实现虚拟节点采集ECI实例的CPU、内存、网络等监控指标。同样，虚拟节点也需要提供/metrics/cadvisor接口，以支持对pod的内存、CPU、网络、文件系统等的监控。
经调研，
1）ack的虚拟节点实现了与kubelet一致的/metrics/cadvisor接口，用以对外提供容器相关指标。
实例内部监听了10250端口，并且跟虚拟节点建立了连接：
创建1个ECI pod，cadvisor数据量为110K左右，查看虚拟节点资源占用情况：
创建10个ECI pod，cadvisor数据量达到1M左右，查看虚拟节点资源占用情况:
可以看到，从1个pod到10个pod，虚拟节点内存占用只增长了4M左右。
应用场景
场景1：虚拟节点容器监控指标在ccse控制台（sce控制台）页面展示
- 策略1：ccse监控插件从arms拉取虚拟节点监控指标
- 策略2：虚拟节点提供/metrics/cadvisor接口，ccse监控插件从虚拟节点获取监控指标并展示
场景2：虚拟节点容器监控指标推送到arms
- 策略1：虚拟节点提供/metrics/cadvisor接口，ccse监控插件从虚拟节点采集指标数据并推送到arms
- 策略2：虚拟节点直接推送到arms
- 策略3：ECI实例直接推送到arms，虚拟节点不处理
场景3：prometheus采集虚拟节点容器监控指标提供给第三方
- 策略1：虚拟节点提供/metrics/cadvisor接口，供第三方采集
- 策略2：第三方从arms拉取虚拟节点监控指标
- 策略3：虚拟节点支持配置推送到第三方
场景4：虚拟节点容器监控指标提供给HPA使用
方案设计
-
方案1：虚拟节点提供/metrics/cadvisor接口（缓存）
虚拟节点采集ECI实例的容器指标数据对接的是ECI-agent中的cadvisor接口：
-
采集服务：虚拟节点定时遍历获取所有容器指标数据
-
数据处理：对获取到的容器指标数据进行填充或清理
-
数据缓存：缓存所有容器最新监控指标数据
缓存数据处理后所有容器的指标数据，只保留最新的数据
-
对外服务：对外提供/metrics/cadvisor接口，从缓存中获取监控指标数据再返回
-
数据监控：对于采集失败的容器，记录并告警（容器不正常导
采集失败的容器记录到日志中，如果超过一定时间都没采集到该容器数据，则告警到虚拟节点的监控指标中
-
致采不到数据的情况不考虑）
-
- 方案2：虚拟节点推送容器监控指标到arms
数据推送：缓存数据到达一定量后调用arms接口，或者达到定时时间间隔就调用arms接口推送数据。
数据监控：采集失败的容器记录到日志中，如果超过一定时间都没采集到该容器数据，则告警到虚拟节点的监控指标中；推送失败记录到日志中，超过一定时间内都推送失败，则告警到虚拟节点的监控指标中。
- 方案3：融合方案，虚拟节点推送容器监控指标到arms，并提供/metrics/cadvisor接口
数据推送：缓存数据到达一定量后调用arms接口，或者达到定时时间间隔就调用arms接口推送数据。
数据缓存：只缓存所有容器指定基础指标的数据，并只保留最新数据
数据监控：采集失败的容器记录到日志中，如果超过一定时间都没采集到该容器数据，则告警到虚拟节点的监控指标中；推送失败记录到日志中，超过一定时间内都推送失败，则告警到虚拟节点的监控指标中。
优劣势对比
| 方案 | 方案1：虚拟节点提供/metrics/cadvisor接口（缓存） | 方案2：虚拟节点推送容器监控指标到arms | 方案3：融合方案，虚拟节点推送容器监控指标到arms，并提供/metrics/cadvisor接口 |
|---|---|---|---|
| 存在的问题 | 1、当虚拟节点管理的pod数量增大，占用内存过高 2、数据处理过程占用内存较高 |
1、推送失败存在丢失一段时间内监控指标的风险 2、涉及ccse监控等外部插件的改动 3、数据处理过程占用内存较高 |
1、推送失败存在丢失一段时间内监控指标的风险 2、当虚拟节点管理的pod数量增大，还是会占用部分内存 3、数据处理过程占用内存较高 |
| 优势 | 1、与普通节点保持一致，业务兼容性高 2、请求即时返回，用户体验好 |
1、不需要对接其他业务，只上报到arms，业务目标明确； 2、不用缓存大量指标数据，占用内存小； |
1、与普通节点保持一致，业务兼容性高； 2、只需缓存少量指标数据，占用内存较小； 3、请求能即时返回基础指标数据，详细指标可从arms获取； |
资源消耗情况
方案1：虚拟节点提供/metrics/cadvisor接口
| pod个数 | 数据大小 | 峰值内存 | 最小内存 |
|---|---|---|---|
| 1 | 68.31KB | 11.539307 MB | 6.192055 MB |
| 100 | 6.15MB | 126.820206 MB | 41.492966 MB |
| 1000 | 61.43MB | 1504.873192 MB | 432.292625 MB |
| 2000 | 122.74MB | 3588.519409 MB | 699.981644 MB |
方案1：虚拟节点提供/metrics/cadvisor接口（优化后）
| 优化前 | 优化后 |
|---|---|
| 无协程池控制并发 | 增加协程池控制并发协程数（500） |
| 所有pod都获取到数据后再存储更新缓存 | 每个pod获取到数据之后先存储起来，再统一删除不存在的pod； |
| 缓存cadvisor返回的指标数据结构体 | 将数据处理后的数据结构体转成string再存储 |
| 处理缓存数据，对指标数据进行合并后再返回 | 调用接口直接返回缓存的string； |
| pod个数 | 数据大小 | 峰值内存 | 最小内存 | 采集耗时 |
|---|---|---|---|---|
| 1 | 68.31KB | 13.340675 MB | 7.090134 MB | 49.2864ms |
| 10 | 681.97KB | 14.679649 MB | 7.673645 MB | 158.2419ms |
| 100 | 6.82MB | 56.944633 MB | 18.985733 MB | 965.8332ms |
| 1000 | 68.20MB | 668.788277 MB | 127.175316 MB | 9.1484256s |
| 2000 | 136.40MB | 1237.441261 MB | 269.664116 MB | 16.0854393s |
| 5000 | 341MB | 4390.664368 MB | 455.211411 MB | 27.2741929s |
峰值内存占用主要是在于数据处理过程中，需要解析数据导致内存占用增大。
后续优化方向：
- 在数据处理过程中，可以分批处理数据，限制峰值内存最大不超过2G。
- 数据处理再删除不必要的数据，减小缓存数据大小。
- 考虑缓存数据只保留多长时间，需跟ccse 监控插件约定只能拉取多长时间内的数据，拉完就删。
- 不进行数据处理，获取到数据直接存储或推送。（不考虑）
发表评论
