实验四：K8s集群部署与持久化存储

用户735

用户3092

5月12日修改

有困难先找 AI

本实验比实验三更容易出现“本地能跑、进了集群就不通”的问题。遇到报错时，不要只发一句“为什么 Pod 起不来”，而要把下面这些信息一起发给 AI：​

•
你当前做到哪一步了​

•
你执行的完整命令​

•
报错原文​

•
相关 YAML 清单​

•
kubectl get pods -o wide​

•
kubectl describe pod <pod-name>​

•
kubectl logs <pod-name> --tail 100​

•
kubectl get svc,pvc​

•
kubectl get events --sort-by=.lastTimestamp | tail -n 30​

推荐提问方式：

•
贴出 gateway 的 Deployment 和 Service，问“为什么 port-forward 能访问，但集群内还是连不上 ollama”​

•
贴出 pvc 和 describe pvc 结果，问“为什么 PVC 一直是 Pending”​

•
贴出 gateway 的环境变量配置，问“为什么代码里明明配置了 Chroma，但 readyz 还是失败”​

实验目标

本次实验需要把实验三基于 Docker Compose 的 CourseBot 系统迁移到 Kubernetes 中运行，并且通过 PVC 保证关键数据在 Pod 重启后不会丢失。​

本次实验的目标如下：

1.
准备一个可用的 Kubernetes 集群环境，并能用 kubectl 正常操作。​

2.
使用 default namespace，不额外创建 namespace 资源。​

3.
将 gateway、redis、chroma、ollama 迁移为 Kubernetes 资源。​

4.
为 Chroma 数据目录和 Ollama 模型目录配置 PVC。​

5.
让 gateway 在 K8s 中通过 Service 名称访问依赖，而不是写死 localhost。​

6.
通过 port-forward 或 NodePort 成功访问 gateway，完成最小问答链路验证。​

7.
证明 Pod 重启后向量库数据和模型缓存仍然存在。​

本实验有几个重要边界，请先看清楚：

•
固定使用 default namespace。​

•
不要求你引入 Helm、Ingress、StatefulSet。​

•
不要求你现在就做自动扩缩容、监控看板或安全加固。​

•
如果你在实验三里已经把 retriever 和 ingestor 拆成独立服务，实验四建议继续迁移；如果还没有完全拆开，本实验最低要求仍然是先把核心链路迁到 K8s。​

为了降低迁移难度，下面的示例统一假设你已经有实验三的代码基础，并继续沿用：​

•
Python 3.11​

•
FastAPI​

•
Redis​

•
Ollama​

•
Chroma​

•
kubectl​

建议完成顺序

不要一上来就同时写所有 YAML。推荐顺序如下：

1.
先确认实验三已经完成，至少本地 docker compose up -d 能跑通。​

2.
准备 K8s 集群，并确认 kubectl get nodes 正常。​

3.
先把镜像构建策略想清楚，再写清单。​

4.
先部署 redis、chroma、ollama，把依赖层跑起来。​

5.
先验证 PVC 是否成功绑定，再部署 gateway。​

6.
gateway 跑起来后，优先用 port-forward 验证。​

7.
全链路确认没问题后，再加 NodePort 暴露。​

8.
最后做“Pod 重启后数据仍在”的验证实验。​

只要你每一步都能“单独验证成功”，K8s 这次迁移并不难。

1. 实验准备

1.1 先确认你已经完成实验三

实验四：K8s集群部署与持久化存储​