MCP Server 云原生实践：从单机进程到 Kubernetes 弹性部署

MCP Server 这个词，最近一年在 AI 工程圈里出现频率高得吓人。它是 Model Context Protocol 的服务端实现，说白了就是给大模型开一批“外挂工具接口”——大模型要查天气、读数据库、操作内部业务系统，都是通过 MCP 协议去调服务端暴露出来的工具。我自己最开始也是随手在本地起了几个单机进程，用 stdio 传输调通 Demo 就以为完事了，直到某一天需要把同一个 MCP Server 同时供多个业务方调用，才发现单机版完全撑不住：进程一崩全线瘫痪，流量一高 CPU 直接打满，想加一台机器都不知道从哪下手。

这篇文章把我在实际项目中，把 MCP Server 从单机进程改造成 Docker 镜像，再部署到 Kubernetes 集群、配上弹性伸缩的全过程整理出来。整个过程踩了不少坑，尤其是容器内网络、健康检查、HPA 指标采集这几个环节，网上资料又碎又旧，很多例子还停留在“能跑通”的水平，离“能上线”差着十万八千里。我会把每个关键决策背后的原因也讲清楚，不只是甩配置，因为只有理解了为什么，换一套业务你才知道怎么改。适合谁看？已经写过 MCP Server Demo、想把它推到生产环境的人，或者正在做 AI 基础设施规划、需要给多个模型应用提供统一工具接入层的后端工程师。

1. 为什么“能跑的 MCP Server”和“能用的 MCP Server”差着一整个云原生

1.1 单机部署的三个原罪

先说单机 MCP Server 最常见的运行方式。大多数 MCP 官方 SDK 默认的传输方式是 stdio，也就是 AI 应用直接 fork 一个子进程，通过标准输入输出来交换 JSON-RPC 消息。这种方式做本地 Demo 非常爽，npx或python一条命令就能把服务拉起来，但一旦进入多人协作、多业务方调用的阶段，问题立刻暴露。

第一个问题是环境耦合。服务依赖本机的 Python 版本、Node 版本、系统动态库，甚至环境变量。我遇到过同一个仓库的 MCP Server，在 A 同事的机器上跑得好好的，换到 B 同事机器上就报缺依赖，最后发现是 B 机器上全局 Python 包污染了虚拟环境。第二个问题是无法横向扩容。单机进程绑死了客户端的并发数，一个 MCP Server 里如果有一个慢工具（比如调外部 API 要等 5 秒），并发一上来，其他所有工具调用全部排队。第三个问题是没有故障转移。进程挂了就是挂了，AI 应用侧只会收到连接断开的报错，没有任何机制帮你拉起新进程。

有人会说，那我改用 HTTP 传输不就解决一部分了吗？确实，MCP 协议支持 HTTP 和 SSE 传输，可以让多个客户端通过一个网络端点访问同一个服务进程。但服务器进程本身依然是脆弱的：没有资源隔离、没有重启策略、没有多副本负载均衡。网络化只是解决了“能不能被远程调用”，并没有解决“进程挂了怎么办”和“流量大了怎么扛”。

1.2 云原生化到底解决了什么问题

把 MCP Server 容器化并跑在 Kubernetes 上，本质上解决的就是上面那几个原罪。Docker 提供不可变交付物，镜像里打包好完整运行环境，彻底消灭“在我机器上是好的”这种问题。Kubernetes 提供调度、副本、健康检查、滚动更新和弹性伸缩，MCP Server 从一个“需要人肉维护的进程”变成“声明式描述的资源对象”。

这张表可以很直观地看出差异：

我见过太多团队卡在“Demo 能用但不敢上生产”这个阶段，其实就是差了这一整套云原生的思维转变：从关注“怎么把进程跑起来”，转向关注“怎么让服务稳定地对外提供能力”。接下来我就按自己的实操顺序，从容器化开始一步步讲。

2. 第一步容器化：把 MCP Server 改造成可分发、可重启的镜像

2.1 技术选型：为什么我选择 Python + FastMCP 而不是其他组合

MCP Server 的 SDK 生态现在很丰富了，官方有 Python 和 TypeScript SDK，社区有各种封装。我在这个项目里最终选了 Python 3.12 + FastMCP，主要原因是团队后端以 Python 为主，且 FastMCP 对 HTTP 传输和 FastAPI 挂载的支持非常顺手。Node 版当然也可以，但如果你要在这个服务里做一些数据预处理、连接传统数据库的活，Python 生态的便利性确实无法抗拒。

我要多提一句选型逻辑：如果你们的 MCP Server 主要是转发调用第三方 HTTP API，那 Node 和 Python 没本质区别，选团队熟悉的语言更重要；如果 MCP Server 内部要做模型推理、向量检索、复杂数据处理，那 Python 几乎是唯一合理选择。另外，FastMCP 虽然好用，但要注意它迭代很快，版本兼容性要锁死，我吃过升级后配置字段变更的亏，后面故障排查部分会细说。

下面是我在项目里实际用的一个工具服务骨架，外部 AI 客户端通过 HTTP 调用get_document这个工具：

# src/main.py from fastapi import FastAPI from fastmcp import FastMCP mcp = FastMCP( "doc-search-server", instructions="提供文档检索服务，支持按关键词查找内部知识库", ) app = FastAPI() # 独立健康检查端点，不给 MCP 协议层管 @app.get("/health") def health(): return {"status": "ok", "service": "doc-search-server"} @mcp.tool() def get_document(keyword: str, limit: int = 5) -> dict: """按关键词检索文档，返回匹配的文档列表。""" # 这里实际会调用内部搜索服务 results = [ {"title": f"{keyword} 相关文档 {i}", "score": 0.95 - i * 0.1} for i in range(limit) ] return {"keyword": keyword, "results": results} # 把 MCP 的 ASGI 应用挂载到 FastAPI 上 app.mount("/mcp", mcp.stream_app)

这里有个关键细节：为什么把/mcp挂载到/mcp路径而不是根路径？因为生产环境前面大概率还有网关或 Ingress，统一路径前缀方便做路由和鉴权策略。而/health独立存在，是因为健康检查不应该经过 MCP 协议层，探针只需要知道“进程活着、能接受新连接”，而不是去验证整个协议栈完整可用。K8s 的存活探针和就绪探针都打这个端点，判断逻辑简单、响应快，不会引入额外依赖。

2.2 一个能进生产的 Dockerfile：多阶段构建与运行期清理

很多人写的 Dockerfile 就是一个基础镜像加pip install完事。这种镜像在生产环境迟早出问题：镜像体积大、包含构建工具链、运行用户是 root。我用的方案是多阶段构建，把依赖安装和运行环境彻底分开：

FROM python:3.12-slim AS builder ENV UV_COMPILE_BYTECODE=1 \ UV_LINK_MODE=copy \ UV_PYTHON_DOWNLOADS=never WORKDIR /app COPY pyproject.toml uv.lock ./ RUN pip install --no-cache-dir uv \ && uv sync --frozen --no-dev FROM python:3.12-slim # 创建非 root 用户，容器安全基本盘 RUN useradd -m -u 1000 appuser WORKDIR /app COPY --from=builder /app/.venv ./.venv COPY src ./src ENV PATH="/app/.venv/bin:$PATH" \ PYTHONUNBUFFERED=1 EXPOSE 8000 USER appuser CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

多阶段构建的好处有两个：一是最终镜像里只有运行所需的.venv和应用代码，没有编译器、包管理工具这些不再需要的东西，镜像体积能小百分之四五十；二是构建阶段和运行阶段的责任完全分离，builder 阶段想怎么折腾都行，runtime 阶段保持最小化。--no-dev这个参数很多人会忽略，MCP Server 的测试框架、lint 工具一旦被打进生产镜像，等于给攻击者免费送了攻击面。

还有两个细节必须强调。第一，运行用户要切换到非 root：容器里以 root 跑服务，一旦镜像里某个依赖被攻破，权限直接就打到宿主机了。USER appuser一句搞定的事，很多人就是懒得写。第二，PYTHONUNBUFFERED=1这个环境变量，保证 Python 的日志输出不被缓冲，否则容器日志系统会丢掉崩溃前的最后几行输出，排查问题时会让你非常痛苦。

2.3 为容器化改造 Server 代码：传输方式、监听地址与配置

单机版用 stdio 启动的代码，容器化之后有几处必须改动。首先是监听地址，开发时很多人习惯127.0.0.1，但容器里必须监听0.0.0.0，否则外面根本访问不进来。其次是配置外部化，数据库连接串、内部服务的地址、日志级别，全部从环境变量读取，不要在代码里写死。

# src/config.py import os class Settings: transport: str = os.getenv("MCP_TRANSPORT", "http") host: str = os.getenv("MCP_HOST", "0.0.0.0") port: int = int(os.getenv("MCP_PORT", "8000")) log_level: str = os.getenv("LOG_LEVEL", "info") max_concurrent_tasks: int = int(os.getenv("MAX_TOOL_CONCURRENCY", "32")) settings = Settings()

容器化改造最容易被忽视的是信号处理。K8s 在停止 Pod 时会给容器主进程发SIGTERM，如果应用不处理这个信号、不主动关闭正在处理的请求，就会出现“请求放到一半被强制杀”的情况。Uvicorn 对SIGTERM的处理比较完善，会等待当前请求完成再退出，这也是我选 Uvicorn 做进程模型的原因之一。如果你用其他方式启动服务，一定要确认进程对SIGTERM有优雅退出的逻辑。具体到 K8s 配置，terminationGracePeriodSeconds要给足，我一般设 60 秒，给长请求留够收尾时间。

2.4 镜像构建的本地验证清单

镜像构建完别急着 push 到仓库，先本地跑一遍验证。我每次构建后都会做这几项检查：

• docker run -p 8000:8000启动容器，然后curl -s http://127.0.0.1:8000/health，确认返回 200。
• 用 MCP 客户端或curl直接调 POST 接口，验证工具调用链路是通的。
• docker exec进去看一眼进程身份是不是 appuser，确认没有以 root 运行。
• 看启动日志，确认配置从环境变量正确读取，没有硬编码残留。

这些检查看着基础，但每一个都是我在生产环境交过学费换来的。尤其第二条，很多人镜像能起、健康检查也过，但真正调工具时才发现依赖的某个内部服务地址没配到环境变量里，服务一启动就报连接错误。本地验证这十分钟，能省掉后面进 K8s 之后的几小时排查时间。

3. Docker Compose 先做本地集群预演：三个服务联调的实用经验

3.1 compose 文件的设计思路

K8s 的复杂度在本地开发环境不好复现，所以我习惯先用 Docker Compose 做本地集群预演。上面提到我做了文档检索、天气查询、数据库查询三个 MCP Server，本地就要把这几个服务一起编排起来，验证服务发现和互相调用。Compose 文件里最核心的是自定义网络：所有服务挂在同一个 bridge 网络里，就能直接用服务名互相访问，不需要关心 IP 是多少。

# docker-compose.yml services: doc-search: build: ./doc-search environment: - MCP_TRANSPORT=http - MCP_HOST=0.0.0.0 - MCP_PORT=8000 - SEARCH_BACKEND_URL=http://internal-search:9200 ports: - "8101:8000" healthcheck: test: ["CMD", "curl", "-f", "http://127.0.0.1:8000/health"] interval: 10s timeout: 3s retries: 3 weather: build: ./weather environment: - MCP_TRANSPORT=http - MCP_PORT=8000 ports: - "8102:8000" db-query: build: ./db-query environment: - MCP_TRANSPORT=http - MCP_PORT=8000 - DATABASE_URL=${DATABASE_URL} ports: - "8103:8000" networks: default: name: mcp-local-cluster

这里SEARCH_BACKEND_URL我故意写成internal-search:9200，就是演示容器间通过服务名通信的机制。你在本地调试时如果某个服务连不上另一个，第一反应应该是检查服务名拼写和自定义网络，而不是去查什么 IP。

3.2 三个服务联调时的“灵异事件”与根因

第一个坑是健康检查里的curl。Alpine 或 slim 基础镜像里默认没有 curl，我在 compose 里写了healthcheck之后，服务状态一直显示 unhealthy，起初以为是服务起不来，进去docker logs看发现一点问题没有。后来才意识到是容器里根本没有 curl 命令。解决办法有两种：换用 Python 自带的 urllib 写检查命令，或者在镜像里装 curl。我更推荐前者，少装一个二进制就少一份维护负担。如果你用 Node 镜像，可以node -e "fetch('http://127.0.0.1:8000/health').then(r=>{if(r.status!==200)process.exit(1)}).catch(()=>process.exit(1))"，充分利用运行时已有能力。

第二个坑是跨服务调用时地址解析错乱。有一个服务想把请求转发给另一个 MCP Server，我在代码里配了http://localhost:8000，结果连的一直是自己。原因很直白：在容器里，localhost 指向容器自身，而不是宿主机，更不是另一个容器。容器间通信必须用服务名。这个错误在单机运行时永远不会暴露，因为 localhost 确实就是本机服务，但一旦进容器编排就立刻现形。

第三个坑是请求超时设置。MCP 工具里如果有一个是要同步调用外部 API 的，本地可能没问题，但放到 Docker 网络里多了一层 NAT，响应时间会明显变长。如果客户端库的超时设得太短，就会出现“本地好好的，容器里隔三差五超时”。我在设计工具时就开始约定：所有可能超过 3 秒的工具必须返回“任务已提交”而不是阻塞等待结果，从根源上避免长请求问题。

3.3 本地验证完之后要做什么

Compose 本地环境验证功能链路通了之后，你要做一个动作：写一份当前服务列表和端口的说明文档。别小看这一步，后面上 K8s 时要梳理哪些服务需要暴露、哪些只在集群内部通信，这份清单能省掉大量沟通成本。之后就可以开始研究真正的集群部署了，但本地这套环境不要删，开发时改代码、跑回归测试都用得上，Compose 和 K8s 两套环境并行是我现在固定的工作流。

4. 真正上 K8s：Deployment、Service、ConfigMap 三件套的取舍与写法

4.1 无状态服务，所以用 Deployment 而不是 StatefulSet

MCP Server 在设计上应该是一个无状态服务：工具调用之间没有共享内存状态，会话数据放在外部存储（Redis、数据库或对象存储），配置全部通过环境变量或配置中心注入。这样才可以用 Deployment 管理，随便滚动更新、随便扩缩容。

我知道有人会把 MCP Server 做成有状态的，比如在进程内存里维护一个用户 session 的缓存。如果真是这样，K8s 里就该考虑 StatefulSet，但我要奉劝一句：不要在 MCP Server 里维护业务状态。原因很简单，水平伸缩是云原生的命根子，有状态服务在扩容、缩容、故障转移时都要处理数据迁移和重连问题，复杂度成倍上升。把状态挪到独立存储层，MCP Server 就可以像“无状态的函数”一样被调度。

4.2 完整的 YAML 组合：ConfigMap、Deployment、Service

下面这套 YAML 是我经过多次迭代后的基础模板，三个对象配套使用。ConfigMap 管非敏感配置，Deployment 管副本和探针，Service 管负载均衡入口：

# configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mcp-server-config data: MCP_TRANSPORT: "http" MCP_HOST: "0.0.0.0" MCP_PORT: "8000" LOG_LEVEL: "info" MAX_TOOL_CONCURRENCY: "32"

# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: mcp-server labels: app: mcp-server spec: replicas: 2 selector: matchLabels: app: mcp-server template: metadata: labels: app: mcp-server spec: containers: - name: mcp-server image: my-registry.local/mcp-server:v1.4.0 ports: - containerPort: 8000 name: http envFrom: - configMapRef: name: mcp-server-config resources: requests: cpu: 250m memory: 256Mi limits: cpu: "1" memory: 1Gi readinessProbe: httpGet: path: /health port: http initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: httpGet: path: /health port: http initialDelaySeconds: 15 periodSeconds: 20 terminationGracePeriodSeconds: 60

# service.yaml apiVersion: v1 kind: Service metadata: name: mcp-server-svc spec: selector: app: mcp-server ports: - port: 80 targetPort: http

几个关键点展开说一下。第一，resources的requests和limits必须写。K8s 调度器是根据requests决定把 Pod 放在哪个节点的，如果你不写，调度器默认认为这个 Pod 不占资源，集群一忙就会把所有节点塞满。limits则是硬顶，防止某个工具的异常循环把 CPU 打爆拖垮整个节点。

第二，readinessProbe 和 livenessProbe 一定要分开理解。readiness 决定“流量要不要打到这个 Pod 上”，liveness 决定“这个 Pod 要不要被重启”。我们的探针配置里 readiness 的initialDelaySeconds比 liveness 短，是因为服务启动时可能要先等依赖的连接，如果一上来就检查存活，可能误杀正在初始化但很快就能就绪的 Pod。我自己见过因为 liveness 太敏感，服务在启动加载模型时被反复重启的案例，那个痛苦没法形容。

第三，envFrom直接把整个 ConfigMap 注入环境变量。如果你的配置项很多，用这个方式比逐条env清晰得多。注意 ConfigMap 里别放密钥，数据库密码、API Key 这些要用 Secret 或者外部密钥管理系统，ConfigMap 是明文存储的，不符合安全基线。

4.3 暴露方式的选择：ClusterIP、NodePort、Ingress

Service 的类型决定外部怎么访问你的 MCP Server，这块要根据调用方的位置来定。

我目前的方案是集群内部调用用 ClusterIP，集群外部或跨网络调用走 Ingress。但这里有一个 MCP 场景特有的坑：SSE 流式响应。MCP 的 HTTP 传输在请求工具结果时可能是流式的，SSE 连接是长连接，如果 Ingress 开启了响应缓冲，或者超时时间设置得太短，会导致客户端明明已经收到事件却迟迟等不到结束标记，看起来就像请求卡死。

解决办法因 Ingress 控制器而异，通用思路是：在 Ingress 的注解里关掉响应缓冲（对应 Nginx 系就是关闭 proxy-buffering），同时把proxy-read-timeout调大，比如 3600 秒。如果你用的云厂商也有类似参数，记得在建完 Ingress 后拿落地的 MCP 客户端做一个端到端流式调用测试，确认整条链路没有缓冲截断问题。这个坑网上很少人提，但我几乎每次给新环境配置都会碰到。

4.4 滚动更新与优雅下线的配套设置

Deployment 默认是滚动更新，也就是新版本 Pod 逐个创建，等就绪后再把流量切过去。但如果你不配strategy，默认的maxSurge和maxUnavailable是 25%，意思是一次滚动最多允许多创建 25% 的 Pod，同时最多允许 25% 的 Pod 不可用。对 MCP Server 这种有状态依赖外部服务的应用，我更喜欢显式控制：

strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0

maxUnavailable: 0意味着滚动更新期间老版本 Pod 不会先被干掉，新的 Pod 先启动、探针通过、进入 Service 端点列表，再开始终止旧 Pod。这样可以做到发布过程中请求不中断。配上前面容器改造时提到的SIGTERM优雅退出和terminationGracePeriodSeconds: 60，整个发布链路就是平滑的。代价是发布速度会慢一些，但对一个 MCP 工具网关来说，稳定性远比发布速度重要。

5. HPA 弹性伸缩实战：从指标配置到压测验证的完整链路

5.1 HPA 的工作机制与前置条件

HPA（HorizontalPodAutoscaler）是 K8s 内置的弹性伸缩组件，它定期从 metrics-server 拉取 Pod 的资源使用指标，然后和用户设定的目标值比较，决定是否调整副本数。它不直接操作 Pod，而是调整 Deployment 的replicas字段。理解了这一层，就知道它有两条前置条件：一是集群里要装好 metrics-server，否则没有任何指标数据可以计算；二是 Deployment 里的容器必须配置了resources.requests，因为 HPA 计算的是“实际使用量除以 requests”的利用率，不写 requests，HPA 直接无法工作。

我们用的 HPA 版本是autoscaling/v2，它支持同时配置多个指标，只要其中任意一个指标超过目标，就会触发扩容。对 MCP Server 来说，CPU 和内存两个资源指标是最基础的，更进阶的可以接自定义指标（比如基于 Prometheus 的每秒工具调用数）。但我建议先把资源指标跑通、观察到实际扩缩容行为之后，再考虑自定义指标，因为自定义指标会把问题排查的维度从“节点资源”扩展到“整个监控链路”，复杂度完全不同。

5.2 标准 HPA 配置：CPU 与内存都盯着

这是我的 HPA 配置，重点看behavior这一段：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: mcp-server-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: mcp-server minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 50 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 0 policies: - type: Pods value: 2 periodSeconds: 60

CPU 目标值设在 60% 而不是 80%，是因为我想给突发流量留缓冲。如果目标设得太高，一旦流量抖动就猛扩容，流量退去又猛缩，集群资源会被无谓消耗。内存目标设在 80%，主要起保护作用：MCP Server 如果内存失控，很可能是某个工具实现有问题，HPA 会先把副本扩起来分担压力，但同时你要去查代码，而不是指望 HPA 帮你兜底。

behavior部分是控制扩缩容“手感”的关键。scaleUp的stabilizationWindowSeconds: 0意思是扩容不等待、看到指标超标立即行动，扩容步长是每次最多加 2 个 Pod，避免一下子 2 变 10 造成资源争抢。scaleDown的窗口我设了 300 秒，这是因为缩容如果太快，你的服务刚扩容完还没稳定，指标一下降就缩，副本数会来回震荡——业界叫 thrashing。我见过最夸张的情况是副本数在 3 和 8 之间每分钟跳一次，白花资源还没提升可用性。

5.3 用压测验证扩缩容：过程与数据

配置写完后，光看配置不能证明有效，必须压测。我在测试环境用 locust 写了一个简单脚本，模拟 200 个并发客户端持续调用get_document工具，每秒钟的请求量控制在 1000 左右。压测过程中我同时开了三个观测窗口：kubectl get hpa -w看副本数变化、kubectl top pods看实时资源占用、以及服务端日志看有没有请求失败。

在我自己的测试集群上，整个过程大致是这样：压测开始后大约 30 秒，metrics-server 采集到的 CPU 利用率从平时的 20% 左右迅速爬升到 70% 以上，HPA 首次扩容触发，副本数从 2 加到 4。继续压测大约 2 分钟，4 个副本的 CPU 利用率稳定在 60% 上下，HPA 没有再继续扩容，说明 4 个副本在当前流量下已经足够。停止压测后，大概 5 分钟，副本数从 4 慢慢回落到 2，缩容策略生效。整个过程请求成功率保持在 99.9% 以上，没有出现因为扩容中新建 Pod 尚未就绪而导致的大量 503。

这个结果验证了几个点：metrics-server 采集链路正常、HPA 计算逻辑符合预期、扩容时机没有明显滞后。如果你压测时发现副本数一直不动，优先查三件事：一是 metrics-server 有没有数据，二是 Deployment 的容器有没有写resources.requests，三是 HPA 和 Deployment 的selector是否匹配。

5.4 扩缩容行为调优：别让副本数来回弹

HPA 跑通之后，你还会遇到几个需要调优的细节。首先是冷启动时间。MCP Server 的镜像如果很大，或者启动时要加载模型/初始化连接池，那么新 Pod 可能要 30 秒甚至更久才能就绪。如果 HPA 扩容速度比不过流量增长速度，前面几秒还是会有一批请求失败。这就是为什么scaleUp的步长要合理，以及为什么 Pod 的readinessProbe最好只检查进程存活，不要让探针依赖一个可能慢响应的下游服务。

其次是自定义指标的进阶玩法。如果你的 MCP Server 每个工具调用的 CPU 消耗差异很大，比如有的工具是纯内存计算、有的工具要走网络 I/O，那么 CPU 指标可能不能完全反映真实负载。这时可以接入 Prometheus Adapter，把“每秒工具调用数”或“活跃连接数”作为 HPA 指标。但我要提醒：这需要维护一套 Prometheus 监控链路，对团队运维能力要求高，初期先把 CPU/内存玩明白更务实。

最后是集群资源水位的问题。HPA 的maxReplicas不是越大越好，它受限于集群节点资源。我见过一个团队把 max 设成 50，结果扩容到 30 个 Pod 后把节点内存打满，反而把集群压垮了。设置 max 时要估算单副本的资源占用上限，精确到节点剩余资源能支撑多少副本。合理做法是：maxReplicas不超过集群可调度 Pod 容量的 30% 到 50%，留出空间给其他服务。

6. 集群日常运维中我踩过的坑和沉淀下来的经验

6.1 日志与可观测：MCP 请求怎么追

MCP Server 上集群之后，第一个烦恼就是日志。以前单机直接看控制台，现在副本一多，你根本不知道某条日志在哪个 Pod 里。我的做法是：容器日志统一打标准输出到 stdout，然后通过 Promtail 采集到 Loki。在副本不多的情况下，这套组合比 ELK 轻量太多，ELK 在服务规模还没上来时反而成了新的运维负担。

更重要的是结构化日志。让代码里的日志输出 JSON 格式，包含tool_name、client_id、duration_ms、trace_id这些字段。这样不管是按客户端维度、按工具维度、还是按调用链追踪，都能快速过滤定位。尤其是 trace_id，一定要在客户端调用 MCP 工具时透传进来。没有 trace_id，你面对“某个客户端说某个工具很慢”的反馈时，就只能在几千条日志里大海捞针。

6.2 两个让我印象深刻的故障排查实例

第一个故障：新版本镜像发布后，滚动更新卡住，新 Pod 一直处于 pending 状态。起初我以为是资源不足，但kubectl describe pod看事件里没有任何调度失败的记录，反而是 readiness 探针一直失败。最后逐步排查发现，新版本代码里我引入了一个新的 FastAPI 路由前缀，结果/health路径被框架重定向了，探针访问/health返回 404。教训是：每次改代码框架版本或路由结构，都必须回归验证健康检查端点。这个坑非常隐蔽，因为本地curl很可能被重定向跟随了，而 K8s 探针不跟随重定向，直接判定失败。

第二个故障：HPA 配置了但副本数不动，压测半天没有反应。排查过程是这样的：先kubectl get hpa -o yaml看状态，发现CURRENT / TARGET一栏显示unknown / 60%。这说明 HPA 取不到指标。再看 metrics-server 的日志，发现有个错误是关于 metrics.k8s.io API 无法获取容器指标。最后定位到根因：Deployment 里有一个副本的容器没有写resources.requests，而 HPA 计算利用率依赖 requests 作为分母，缺失时就标记为 unknown。这提醒我一个规则：全集群统一资源配额规范，容器必须写 requests，让 HPA 和调度器都有据可循。当时那个裸奔的容器是因为调试临时创建的，结果忘在 Deployment 里，差点让整个 HPA 机制失效。

6.3 做完这套集群后，我对云原生的几点实际感触

第一，容器化和集群化的最大收益不是“高级”，而是消除了单机环境的隐性耦合。以前我调试 MCP Server 时最耗时的就是复现环境问题，现在镜像即环境，任何节点拉起来行为一致，调试效率提高了一个量级。

第二，弹性伸缩不是上了 HPA 就结束了，它是一个需要持续观察和调优的过程。流量模型变了、工具逻辑变了、下游服务慢了，都可能导致原来的扩缩容策略不再合适。我自己的习惯是每个月看一次 HPA 的历史指标和副本数变化记录，比对业务流量节奏，调整目标值和策略参数。这比任何“一次性配好”都重要。

第三，也是我最想说的：MCP Server 的集群化，核心价值不在于“服务不会挂”这种被动稳定性，而在于它把 AI 工具接入层变成了一个可以按需扩展的基础设施。当你的 AI 应用数量增长，当工具调用频率翻了几倍，你不需要再焦虑某台机器够不够用，只需要看着 HPA 自动把副本数调整到合适的位置。这种能睡安稳觉的感觉，才是云原生真正给到的东西。