我在 CNCF 蒙特利尔 KubeCon NA 2025 的收获回顾
Source: Dev.to
（请提供您希望翻译的具体内容，我将为您翻译成简体中文。）
介绍
2025年12月10日，Cloud Native Montreal 社区在亚特兰大举办了 KubeCon NA 2025 的回顾。与传统会议不同，这次活动由社区驱动，包含闪电演讲以及对云原生生态系统未来走向的思考。重点聚焦于生态系统中出现的新模式和经验教训——从 AI 代理和可观测性到 GitOps 以及节能基础设施。
AI 工作负载作为一等公民
一个反复出现的主题是，AI 工作负载现在已经在云原生环境中成为一等公民。传统的可观测性能够回答以下问题：
- 服务是否正常运行？
- 延迟是否在 SLO 范围内？
AI 系统引入了新的运维问题：
- 哪个提示触发了此行为？
- 哪个模型调用成本高？
- 为什么该代理执行了特定操作？
类似 OpenLLMetry 的工具通过为大型语言模型和代理工作流添加仪器化来扩展 OpenTelemetry，而 OpenCost 则提供对 Kubernetes 和云支出在不同工作负载、团队和环境中的可视化。
要点：
你无法在无法观测或不了解其财务情况的情况下扩展 AI 系统。可观测性正从仪表盘和警报演进为以代理辅助的运维。
演进中的可观测性
而不是工程师手动关联指标、日志和最近的部署，新的工具旨在：
- 执行根因分析
- 对警报进行分流
- 推荐修复步骤
像 k8sgpt、Seraph 以及更新的代理式 SRE 工具等项目，暗示了一个未来：可观测性系统不仅仅展示数据——它们还能主动对数据进行推理。
突出工具
- k8sgpt – AI 原生的 Kubernetes 故障排查
- HolmesGPT / Seraph – 自动化根因分析和警报缓解
新兴的基于代理的平台
- AWS DevOps Agent (Preview)
- Azure SRE Agent (Preview)
- Cleric
- Kube Whisperer
这些代理将日志、指标、部署和事件进行关联，以帮助值班工程师并降低警报疲劳。它们并不取代工程师，而是改变工作流程：减少搜索信号的时间，增加做出明智决策的时间。
Cyclops：Kubernetes 的结构化抽象
Cyclops 是一个开源平台，通过用结构化、基于表单的抽象取代原始 YAML，简化了 Kubernetes 的使用。
核心概念
- Modules – 对应用所需的所有 Kubernetes 资源进行逻辑分组
- Templates – 将模块输入映射为有效的 Kubernetes 清单的映射规则
与 Helm 的集成
- Helm Chart 使用模板化的 YAML 定义资源（Deployment、Service、Ingress 等）。
- Cyclops 包装这些 Chart，并将它们的 values 以经过验证的表单形式呈现，而不是自由文本的 YAML 编辑。
- 用户填写表单后，Cyclops 将底层的 Helm 模板渲染为有效的清单。
Cyclops 还通过 Model Context Protocol (MCP) 服务器支持 AI 驱动的运维，允许代理使用自然语言而非直接访问集群来管理应用。
Caution: 由 AI 生成的代码应视为不可信。安全风险仍然存在，随着抽象层次的提升，防护措施、验证和测试变得更加关键。
GitOps 案例研究
一个实用的 GitOps 案例研究强调，仓库结构与工具同等重要。讨论的关键原则：
- 将配置结构与团队所有权对齐
- 在保持环境明确的同时集中管理配置
- 将相关文件放在一起（“邻近性很重要”）
- 优化开发者体验，而不仅仅是正确性
使用 ArgoCD，部署变得自动化、可审计且一致——前提是将 GitOps 视为技术和组织设计的双重因素。
Kepler：能源感知可观测性
Kepler 是一个 CNCF 项目，能够在容器层面公开能源消耗情况。
功能
- 细粒度的容器和进程功耗指标
- 支持 CPU、GPU 以及异构硬件
- 使用 eBPF 实现低开销
- 与现有可观测性栈集成
随着 GPU 密集型和 AI 工作负载的增长，能源使用和冷却成本已成为运营关注点。
核心信息： 可持续性现在是平台工程的一部分，而不仅仅是硬件规划。
Summary
这篇 KubeCon 回顾并不是要记住各种工具，而是要把握发展方向。在各场演讲中，出现了以下一致的转变：
- 从被动监控转向 AI 辅助运维
- 从原始 YAML 转向安全、带有意见的抽象层
- 从成本意外转向成本感知平台
- 从仅关注性能的指标转向关注能耗的基础设施
像这样的社区驱动活动有助于将各个技术连接起来，形成对云原生系统未来走向的统一认知模型。