去年 10 月，我们推出了 红帽 OpenShift 功率监控的开发人员预览版，并将 Kepler 确立为 可持续计算上游社区计划中不可或缺的组成部分。这一举措让早期采用者有机会率试用这项充满前景的技术。自发布以来，我们的团队持续致力于构建符合红帽产品安全和测试标准的管道和工具。
今天，我们满怀喜悦地与大家分享，我们的旅程中又迎来了一个新的里程碑—— 红帽 OpenShift 功率监控的 技术预览版本正式发布。 在此，我们衷心感谢所有积极投身于功率监控部署并慷慨分享宝贵反馈的早期采用者及技术革新爱好者。
对于那些尚未有机会试用红帽 OpenShift 功率监控的用户，值得了解一下：这是一套专为监控 OpenShift 集群中的工作负载功耗而设计的工具。此工具提供的信息可用于多种目的，比如识别功耗最高的命名空间，或制定策略计划以最大限度减少能源消耗。
如果您对体验此预览版感兴趣，下方提供了详细的入门指南。如需官方支持的更多信息，请阅读 技术预览声明。
安装红帽 OpenShift 功率监控
我们的目标是实现统一的用户体验，因此，这些安装步骤与旧版功率监控中依赖 社区 operator 的步骤高度相似。
- 按照红帽 OpenShift 文档中提供的说明，启用 user-workload-monitoring。
- 为避免不必要的冲突，请先卸载已通过社区 operator 目录安装的任何旧版 kepler-operator。
- 从 OpenShift 4.14（及更高版本）控制台，前往 Operators -> OperatorHub 以安装 Operator。然后，使用搜索框查找红帽 OpenShift 功率监控，单击它并按“Install”框。
- 安装了 Operator 后，单击“View Operator”来创建 Kepler Custom Resource Definition 的实例。然后，单击 Kepler API 下的“Create instance”。
大功告成。Kepler 安装完毕后，OpenShift 控制台中的 Observe>Dashboards UI 选项卡下将提供两个新的仪表板：
若要获取有关功率监控的更多信息，强烈建议您阅读 OpenShift 文档下的功率监控官方文档。
监控的作用
通过使用这些仪表板，您现在可以获得有关集群及其工作负载的以下洞察信息：
- 监控集群在过去 24 小时内的总能耗，包括所选 CPU 架构和受监控节点数量。
- 查看能耗最高的命名空间的明细情况。
- 了解哪些容器和容器集的能耗最高。 这可以通过分析“Observe -> Metrics”选项卡下由 Kepler 公开的指标来实现。
- 专业提示：您可以使用以下正则表达式来查询功率监控的所有可用指标：{ __name__ =~ "kepler.+"}
如前文所述，当 Kepler 整合到 OpenShift 中后，这些指标即可使用了。Kepler 获取的指标集合在很大程度上取决于底层硬件和集群配置。目前，Kepler 提供来自一组特定云配置的准确测量，特别是基于英特尔硬件的测量能够在裸机部署中公开 运行平均功率限值（RAPL）和 高级配置和电源接口（ACPI）。
对于其他配置，红帽提供了一个初始的机器学习模型。此外， 红帽正积极与更广泛的社区合作，以进一步提高基于机器学习的估算器的准确性。 目前，这些估计值展现了一致性，可依据它们来揭示相同工作负载在不同运行之间所表现的差异。但请务必注意，这些值是实际功耗的近似值。
为了帮助用户更轻松地识别 Kepler 默认提供的是基于指标的值还是基于模型的值，我们在 Overview 页面的 Node - CPU Architecture 面板中新增了一列，名为“Components Source”。
此增强功能提供了透明度，允许用户查看这些指标的具体来源，例如 rapl-sysfs 或 rapl-msr。 如果 Kepler 无法获取硬件功耗指标，它将显示“estimator” 作为其来源。在这种情况下，Kepler 会回退到机器学习模型和生成的上述估算器。我们持续推进开发工作，重点在于不断完善这些模型，以提升预测的准确性，并拓宽所能解决的问题范围。
探索相关指标
那么，它们究竟是什么样的？我们通过一个示例来深入了解一下。在按照 官方文档安装 Kepler 后，我们安装了 HTTP/2 流量生成器和一个模拟程序，并向系统添加了一些负载。
现在，我们看看这对 OpenShift 集群的功耗所产生的影响。在 OpenShift 控制台中，前往 Observe -> Dashboards -> Power Monitoring Overview 仪表板，现在可以看到：
- Architecture 面板中显示的节点正在报告基于指标的结果，因为 Components Source 列中显示了 rapl-sysfs。
- 集群已启动了一段时间，但目前处于空闲状态，因此功耗没有那么高。
- 图中还显示了能耗最高的命名空间的列表。
还有其他的吗？我们想要了解功耗和能耗配置集，因此跳转到第二个仪表板：“Power Monitoring / Namespace”。在选择我们感兴趣的命名空间（hermes-ns）后：
- 首先可以注意到的是，在经历了几个峰值之后，功耗（以瓦特为单位）随着时间推移逐渐趋于稳定，而其中 PKG 组件是对此贡献最大的部分。封装（PKG）域会测量整个插槽的能耗，包括所有核心、集成显卡和非核心组件（末级缓存、内存控制器）的能耗。 这看起来是合理的，我们也没有发现累积现象，因为功耗实际上是能量的消耗速率。
- 还可以看到，能耗随着时间的推移而增长。在这种情形中，DRAM 的功耗（测量连接到集成内存控制器的 RAM 的能耗）似乎可以忽略不计。
将页面向下滚动一些，可以进一步分析 每个容器对 PKG 和 DRAM 的贡献。首先引起我们注意的是，首批峰值似乎是由先前的工作负载引起的。这听起来很有趣，我们可能需要在 app/mock 中调试它！
在第二个部署准备就绪后，可以观察到两个容器在功耗方面的贡献是相等的。
这说明了什么？这是否意味着，一个具有复杂逻辑和仪表化特征且带有 OpenTelemetry 、指标和跟踪的流量生成器，在能耗方面竟然与仅返回“200 OK”响应并打印到控制台的 简单模拟程序相当？虽然我们更喜欢现代化的可观测性工具，但时不时仍然需要打印到标准输出。
func exampleHandler(w http.ResponseWriter, r *http.Request) {
time.Sleep(2 * time.Millisecond)
fmt.Println("Request received. URI:", r.RequestURI, "Method:", r.Method)
w.WriteHeader(200)
}流量生成器使用 C++ 编写，而模拟程序则使用了 Go。近期研究表明，在特定条件下， C++ 的能效相较于 Go 可高出2.5 倍，但这远远超出了本博客的讨论范畴。我们欣赏每一种语言，因为它们各自都有所长。我们满怀期待地想知道您将如何运用功率监控技术，说不定您还能用自己的数据，加入到关于哪种编程语言更耗电的“大战”中去呢！
后续步骤
我们将不懈努力，收集大家的反馈意见，做出相应调整，并引入增强功能。同时，我们将深化与社区的合作，致力于推动全球更有效地监控能源消耗。展望未来，我们满怀信心，计划将功耗监控与更广泛的可持续发展倡议相结合，助力开发人员在 OpenShift 平台上洞悉代码的表现，或借助 OpenTelemetry 技术导出相关数据。
扩展阅读
关于作者
Jose is a Senior Product Manager at Red Hat OpenShift, with a focus on Observability and Sustainability. His work is deeply related to manage the OpenTelemetry, distributed tracing and power monitoring products in Red Hat OpenShift.
His expertise has been built from previous gigs as a Software Architect, Tech Lead and Product Owner in the telecommunications industry, all the way from the software programming trenches where agile ways of working, a sound CI platform, best testing practices with observability at the center have presented themselves as the main principles that drive every modern successful project.
With a heavy scientific background on physics and a PhD in Computational Materials Engineering, curiousity, openness and a pragmatic view are always expected. Beyond the boardroom, he is a C++ enthusiast and a creative force, contributing symphonic and electronic touches as a keyboardist in metal bands, when he is not playing videogames or lowering lap times at his simracing cockpit.
产品
工具
试用购买与出售
沟通
关于红帽
我们是世界领先的企业开源解决方案供应商，提供包括 Linux、云、容器和 Kubernetes。我们致力于提供经过安全强化的解决方案，从核心数据中心到网络边缘，让企业能够更轻松地跨平台和环境运营。