AI导哈

Kubernetes集群交互服务器

一个专为AI工作流优化的Kubernetes多集群管理服务器，提供简化的HTTP接口和令牌认证，支持资源列表、获取和应用操作。

  • by ardaguclu
  • Go
  • 本地部署
  • 更新于
在 GitHub 查看 ardaguclu/k-mcp

使用说明

k-mcp

MCP服务器与Kubernetes集群交互

关于

该项目的灵感来自并建立在以下优秀工作的基础上 kubernetes mcp服务器. 我们钦佩他们的做法；然而，这个存储库试图提供一种替代解决方案来消除某些痛点

主要区别

  • 仅限流式HTTP：与支持多种传输方法的其他MCP服务器不同，此服务器仅使用Streamable HTTP
  • 基于令牌的身份验证：此服务器只接受用于身份验证的令牌，不支持kubeconfig文件。因此，MCP服务器不依赖于任何kubeconfig配置
  • 多集群单租户：支持具有单租户架构的多集群环境，允许通过基于令牌的身份验证访问多个Kubernetes集群
  • 无删除操作：出于安全原因，此服务器不支持DELETE操作。 注意：一些更新操作可能会触发Kubernetes垃圾回收来修剪相关资源
  • 简化方法：专注于简化体验，减少配置选项

为什么存在此存储库

动机

当前的MCP服务器通过1:1的函数调用映射来反映kubectl的交互模式。例如，对失败的应用程序进行故障排除需要多个单独的调用：首先列出Pod，然后获取特定Pod的日志，然后描述这些Pod以获取更多详细信息。 虽然这种循序渐进的方法对于使用CLI工具的人类操作员来说效果很好，但在使用AI代理时，它会产生低效的来回通信。

当人工智能代理能够在更少的操作中收集全面的上下文时，他们表现出色。它们受益于智能工具功能，而不是多个粒度调用，这些功能可以自动收集相关数据集并在单个响应中返回完整信息。

这个存储库采用了一种根本不同的方法——设计一个专门针对AI工作流程优化的MCP服务器，而不是简单地复制kubectl以人为中心的交互模式。

我们不需要什么

  • kubeconfig风险：完全删除kubeconfig消除了杠杆访问的风险。由于我们不存储任何kubeconfig文件，MCP服务器不会暴露任何凭据泄漏或存储敏感数据的风险
  • CLI工具依赖关系：不依赖kubectl或任何其他CLI工具。服务器直接与Kubernetes API通信，消除了外部命令依赖关系，提高了可靠性
  • STDIO传输：我们的HTTP架构不需要标准的输入/输出传输方法
  • 服务器发送事件（SSE）：SSE支持已弃用，并增加了不必要的复杂性
  • 删除操作：支持删除操作可能会导致意外问题和意外资源删除

可用工具（将更新更多工具）

此MCP服务器提供了三个与Kubernetes集群交互的核心工具：

资源列表

列出特定类型的Kubernetes资源。支持按命名空间和标签选择器进行筛选。

  • 参数：资源类型（必需）、命名空间（可选）、标签选择器（可选）
  • 示例：列出默认命名空间中具有特定标签的所有Pod
  • 只读操作 无副作用

资源集合

检索特定Kubernetes资源的详细信息。

  • 参数：资源类型（必需）、资源名称（必需）和命名空间（命名空间资源可选）
  • 示例：获取特定部署的详细信息
  • 只读操作 无副作用

资源_应用程序

使用服务器端应用程序应用Kubernetes资源。支持单个资源和由分隔的多个资源 ---.

  • 参数：资源YAML（必需）
  • 特性：模拟运行验证、用户确认提示、多文档YAML支持
  • 破坏性操作 可以修改集群状态

所有工具通过基于JWT令牌的身份验证支持多个API服务器，并通过用户友好的消息提供全面的错误处理。服务器使用Kubernetes发现API动态访问集群中的所有实时资源，从而消除了对预配置资源定义的需求。

安全限制

为了提高安全性，此MCP服务器明确限制对某些敏感Kubernetes资源的访问：

受限资源

  • 秘密 (secrets.v1)：包含密码、令牌和证书等敏感数据
  • 服务帐户 (serviceaccounts.v1)：管理身份验证令牌和群集访问凭据
  • 所有RBAC资源 (*.rbac.authorization.k8s.io)：包括角色、角色绑定、集群角色和控制集群权限的集群角色绑定

这些资源在发现过程中被完全过滤掉，不会出现在资源列表中，也不会通过任何MCP工具访问。尝试访问它们将导致“找不到资源”错误。

设置和使用

先决条件

  • 亲切的 用于本地Kubernetes开发
  • kubectl CLI工具

逐步设置

1.创建一个类集群

kind create cluster --name k-mcp-demo
kubectl cluster-info --context kind-k-mcp-demo

2.导出群集证书颁发机构

类集群生成自己的证书颁发机构。将其解压缩到MCP服务器的文件中：

kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.cert

3.创建服务帐户

kubectl create serviceaccount k-mcp-sa

4.授予必要的权限

为服务帐户创建适当的RBAC权限：

# Create ClusterRole with necessary permissions
kubectl create clusterrole k-mcp-role \
  --verb=get,list,watch,create,update,patch,apply \
  --resource=*

# Bind the ClusterRole to the service account
kubectl create clusterrolebinding k-mcp-binding \
  --clusterrole=k-mcp-role \
  --serviceaccount=default:k-mcp-sa

备注：根据您的安全要求调整权限。对于生产用途，请考虑使用更严格的权限。

5.生成服务帐户令牌

k-mcp服务器需要具有特定受众配置的JWT令牌。信物 必须 按此顺序包括三个受众：

  1. 第一批观众：您的Kubernetes API服务器URL
  2. 第二位观众：MCP服务器受众（默认值：“k-MCP”，或通过以下方式设置的自定义值 --audience 旗帜）
  3. 第三位观众：默认受众（可以通过以下方式检查 kubectl create token default)
获取您的API服务器URL
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
检查默认受众
kubectl create token default

这将向您显示集群使用的默认受众格式。

使用正确的受众创建令牌
# Replace <API_SERVER_URL> with your actual API server URL
# Replace <MCP_AUDIENCE> with your MCP server audience (default: "k-mcp")
# Replace <DEFAULT_AUDIENCE> with your cluster's default audience

kubectl create token k-mcp-sa \
  --audience=<API_SERVER_URL> \
  --audience=<MCP_AUDIENCE> \
  --audience=<DEFAULT_AUDIENCE> \
  --duration=24h

例子:

kubectl create token k-mcp-sa \
  --audience=https://127.0.0.1:6443 \
  --audience=k-mcp \
  --audience=default \
  --duration=24h

#### 6. Start the MCP Server

```bash
# Using default settings (port 8080, audience "k-mcp") with CA certificate
./k-mcp --certificate-authority ca.cert

# Using custom settings with CA certificate
./k-mcp --port 9090 --audience my-custom-mcp --certificate-authority ca.cert

7.配置您的MCP客户端

使用生成的令牌向MCP服务器进行身份验证。通过将服务器配置添加到您的MCP客户端（如Claude Desktop）来配置MCP客户端 mcp.json 文件：

{
  "mcpServers": {
    "k-mcp": {
      "url": "http://localhost:8080/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_SERVICE_ACCOUNT_TOKEN>"
      }
    }
  }
}

替换 <YOUR_SERVICE_ACCOUNT_TOKEN> 其中令牌是在步骤5中生成的。

重要:

  • 如果您通过指定了自定义受众 --audience 在启动服务器时标记，确保您的令牌将确切的受众作为第二个受众参数。
  • 此MCP服务器支持多个Kubernetes集群，只要JWT发行者相同，并且受众在令牌中正确对齐。

令牌要求摘要

  • 过期：令牌不得过期
  • 之前没有：令牌当前必须有效（如果存在nbf声明）
  • 受众：必须恰好包含三个受众：
    1. Kubernetes API服务器URL（用于集群通信）
    2. MCP服务器受众（用于服务器身份验证）
    3. 默认受众（集群默认）

安全考虑

  • 服务帐户令牌的生命周期有限-根据需要重新生成
  • 分配RBAC权限时使用最小特权原则
  • 尽可能考虑使用命名空间范围的角色而不是集群角色
  • 定期轮换服务帐户令牌
  • 安全地存储令牌并避免记录它们

此自述文件主要是在生成式人工智能的帮助下生成的。

相关 MCP