mcp-k8s 是一款专为 Kubernetes 设计的 MCP 服务器，它充当 AI 模型与 Kubernetes 集群之间的桥梁。通过标准的 MCP 协议，它使大型语言模型 (LLM) 等 AI 能够查询和管理 Kubernetes 资源。其核心功能包括发现集群支持的资源类型，以及对资源执行精细可控的 CRUD (创建、读取、更新、删除) 操作，并使用标准的 kubeconfig 文件进行集群连接认证。这极大地简化了开发和运维人员的工作，允许他们通过自然语言交互来管理复杂的 Kubernetes 环境，替代繁琐的 kubectl 命令。mcp-k8s 基于 Go 语言和 client-go 库构建，可通过标准输入/输出 (stdio) 或 HTTP/SSE 方式与 MCP 客户端无缝集成，为 AI 驱动的 Kubernetes 自动化运维和资源管理提供了强大支持。

K8s资源类型发现

mcp-k8s 核心功能之一是使 AI 模型能够动态发现目标 Kubernetes 集群所支持的资源类型。这包括 Kubernetes 内置的标准资源（如 Pods, Deployments, Services）以及通过 Custom Resource Definitions (CRDs) 添加的自定义资源。该功能通过 get_api_resources MCP 工具实现。当 AI 模型（通过 MCP 客户端）调用此工具时，mcp-k8s 服务器会利用其内部的 Kubernetes client-go 库与 Kubernetes API 服务器通信，查询 /apis 和 /api 端点以获取完整的可用 API 资源列表。服务器随后将这些信息格式化并通过 MCP 协议返回给 AI 模型。这对 AI 模型至关重要，因为它能在执行具体操作前了解集群的能力范围，避免尝试操作不存在的资源类型。例如，一个运维 AI 助手在被要求“检查所有数据库实例”时，可以先调用 get_api_resources 确认是否存在如 Database 或 PostgreSQLCluster 这样的 CRD，然后再进行后续查询。这为 AI 提供了上下文感知能力，使其能更智能、更准确地与特定 Kubernetes 环境交互。

K8s资源查询与读取

mcp-k8s 提供了强大的 Kubernetes 资源查询和读取能力，允许 AI 模型通过标准化的 MCP 接口获取集群状态信息。这主要通过 list_resources 和 get_resource 两个 MCP 工具实现。list_resources 工具允许 AI 请求特定类型的所有资源实例列表，可以指定命名空间或查询集群范围的资源。例如，AI 可以请求“列出 'production' 命名空间中的所有 Pod”。get_resource 工具则用于获取单个特定资源的详细信息（通常是其 YAML 或 JSON 定义），例如“获取名为 'nginx-deployment' 的 Deployment 的详细配置”。在后台，mcp-k8s 接收到这些工具调用请求后，会解析参数（资源类型、名称、命名空间等），然后使用 client-go 库向 Kubernetes API 服务器发起相应的 GET 请求。获取到的资源数据经过处理和格式化后，通过 MCP 协议返回给 AI 模型。这项功能使 AI 能够获取实时、准确的集群状态，是进行问题诊断、配置审计或生成报告的基础。开发者可以通过自然语言让 AI 查询资源，而无需记住复杂的 kubectl 命令语法。

可控的K8s资源操作

mcp-k8s 不仅能读取 Kubernetes 资源，还能执行创建（Create）、更新（Update）和删除（Delete）等写操作，但其核心价值在于这些写操作是可配置和可控的。管理员在启动 mcp-k8s 服务器时，可以通过命令行参数（-enable-create, -enable-update, -enable-delete）独立地启用或禁用这三类写操作。默认情况下，所有写操作都是禁用的，以确保安全。这为 AI 模型与 Kubernetes 集群的交互提供了一个重要的安全层。例如，一个用于监控和告警的 AI 助手可能只需要读取权限，管理员可以只启用 -enable-list（默认启用）和相关的读取工具，而禁用所有写操作。而一个用于自动化部署或测试环境管理的 AI，则可能需要被授予创建和删除资源的权限，此时管理员可以显式启用 -enable-create 和 -enable-delete。这种精细化的控制允许根据具体用例和信任级别调整 AI 的能力，防止意外或恶意的修改。当 AI 通过 MCP 客户端调用如 create_resource, update_resource, 或 delete_resource 工具时，mcp-k8s 会首先检查对应的启用标志，只有在标志为真时，才会通过 client-go 执行相应的 Kubernetes API 调用。