iFlow CLI + ACK MCP Server：让 ACK 容器运维进入对话时代

原创于 2025-12-31 14:15:23 发布 · 690 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#运维 #iFlow CLI #iFlow #iflow #ACK

作者：薇溪

背景：ACK 与 AI 时代下的云原生底座

ACK（Alibaba Cloud Container Service for Kubernetes）

是阿里云提供的托管 Kubernetes 服务，是企业在阿里云上构建云原生应用的基础平台。它提供从集群创建、弹性伸缩、网络与存储集成，到安全合规、可观测、混合云/多集群管理的一整套能力。

市场与成熟度

ACK 已经连续多年在 Gartner 容器管理魔力象限中进入“领导者”象限，是亚太地区唯一连续三年入选领导者的云厂商之一，这意味着它在大规模生产实践、功能完备性和客户体验上已经经过充分验证。
对很多客户而言，ACK 已经是“默认”的 Kubernetes 平台，是业务和基础设施演进的长期依托。

ACK 在 AI 时代扮演的新角色

Kubernetes 已成为企业应用的统一承载层，新一代 AI 原生应用（模型推理服务、Agent 应用）同样在大规模跑在 ACK 上；
ACK 集成了完善的监控、日志、审计、安全等基础能力，为 AI 做运维决策提供高质量数据；
最重要的是，托管服务的特点，使得很多复杂的控制面运维能力可以沉淀为“平台级工具”，再通过 AI 统一编排和开放给客户使用。

痛点：传统运维与“半截子 AI”方案的不足

传统容器运维的痛点

认知负担重：运维工程师需要同时理解 Kubernetes 内部机制、云产品特性、网络拓扑、存储性能、安全策略，可观测体系（Metrics/Log/Trace）等。

工具割裂：日常排障要在 kubectl、ACK 控制台、Prometheus、日志系统、审计系统之间来回切换，信息和决策多靠人脑整合。且复杂场景比如跨可用区高可用设计、调度策略设计、成本治理、容量规划等，缺乏标准化、自动化手段，大量决策靠“资深工程师经验”。

正因为 ACK 已经成为企业云原生和 AI 负载的“标准底座”，我们才希望回答这样一个问题：

在这样一个高度标准化、可观测、可自动化的平台上，AI 能为运维带来多大增量？
如何把 ACK 多年来积累的专家经验、诊断工具，通过 AI 的方式开放出来？

第一代 AI 运维尝试

Day 0 - 辅助集群架构设计/ Day 1 - k8s YAML 智能生成及优化
我们 ACK AI 助手功能的初版基于 RAG + LLM 的架构，在2023年11月上线。
擅长 QA、推荐等场景，但是但看不到真实集群状态，也无法“动手”处理复杂运维场景。据售后同学的数据，所有对客工单的采纳率，只能达到 56%，对复杂问题的采纳能力遇到上升瓶颈。

但伴随着过去两年 AI 的极速崛起，在具体到容器和云原生基础设施运维时，我们遇到的真实问题是：
一边震撼于 AI 提供的更复杂的决策和自动化执行能力，一边在日常运维中感受到工具与问题之间的巨大鸿沟。简单的聊天建议已经不足以闭环解决生产上涉及到真实集群、真实风险的问题。
所以新的运维范式应运而生。

基于 MCP 的集群运维阶段

先看需求：客户到底哪里最痛、最缺人、最容易出错、最难标准化？
再选技术：在这些场景上，用 AI 做怎样的“增量”最有价值？
最后打磨：

- 我们的用户，希望构建自己的 AI Agent，且有价值。
- 客户要用我们的应用，就要用最专业的。需要最专业的应用，成为这个领域的专家，且可被客户集成。

这篇分享要回答的核心问题是：

在 Kubernetes / 云原生运维场景里，AI 究竟能带来多大提效？

我们又是如何通过 ACK AI 助手与开源的 ack-mcp-server，把“AI 问答助手”升级成“能读懂、能操作、能闭环”的运维 Agent。

ACK-MCP-Server

LM – MCP Host – ack-mcp-server – 实际资源

可以用一句话概括架构：

LLM 负责理解自然语言和规划动作；
MCP Host（iFlow）负责对话、会话管理、权限上下文；
ack-mcp-server 负责把 Kubernetes 和 ACK 相关能力封装成标准工具；
底层对接真实的集群、可观测系统、审计和诊断服务。

也就是说，ack-mcp-server 是“容器智能运维能力的入口”，上接各种 LLM 和 Agent，下接 ACK 的真实能力。

效果演示

case 1: 发现并修复一个 OOM 的 Pod

案例说明：作为 ACK 集群的运维人员，观测到集群的异常后，需要进行修复，本案例将展示发现并修复一个 OOM Pod 的能力

https://live.youkuaiyun.com/v/508177https://live.youkuaiyun.com/v/508177

Case 2：获取集群的审计日志

案例说明：作为ACK集群的运维人员，需要查询集群的历史审计以追踪资源变化，本案例将展示获取集群审计日志的能力

https://live.youkuaiyun.com/v/508182https://live.youkuaiyun.com/v/508182

case3: 集群风险识别与修复

案例说明：作为ACK集群的运维人员，需要检测获取集群的风险，并进行修复，本案例展示CoreDns单可用区风险的识别与修复

https://live.youkuaiyun.com/v/508184https://live.youkuaiyun.com/v/508184

今天的效果case可以说明，具备：

1、能完全操作资源的全生命周期

2、以及能完全AI闭环掉运维操作的完整过程：问题分析、数据观测收集、根因诊断、完成修复

可以覆盖和被采纳更多售后团队运维问题。

节省的人力成本、运维复杂度成本足以形成运维产品能力竞争力，足以让我相信那句话“所有的原有服务都应该结合AI重做一遍”。