k8s演示项目中直接使用 Python 的内置 HTTP 服务器来托管静态文件。

直接使用 Python 的内置 HTTP 服务器来托管静态文件。

🧐 为什么没有 Web 服务器镜像？

        因为在开发或演示阶段，前端只是纯粹的静态 HTML、CSS 和 JavaScript，并不需要复杂的反向代理或负载均衡。项目选择用最简单的方式让这些文件能够被访问。

        具体来看项目中的 docker-compose.yml 和 Kubernetes 部署文件，你会发现前端服务的定义是这样的：

1. 在 Docker Compose 中

在 docker-compose.yml 文件里，前端服务通常会这样配置（我根据常见模式还原）：

yaml

camp-web-frontend:
build:
context: ./camp-web-frontend
dockerfile: Dockerfile # 前端有自己的 Dockerfile
ports:
– "3004:3004"

而前端的 Dockerfile（在 camp-web-frontend/Dockerfile 中）内容极简，类似：

dockerfile

FROM python:3.9-alpine
WORKDIR /app
COPY . .
EXPOSE 3004
CMD ["python", "-m", "http.server", "3004"]

它并没有拉取任何第三方 Web 服务器镜像，而是基于 python:3.9-alpine 这个基础镜像，然后直接使用 Python 自带的 http.server 模块来启动一个简单的静态文件服务器。所以，你看到的“镜像”实际上是 Python 基础镜像，而不是 Nginx 或 Apache。

2. 在 Kubernetes 中

在 Kubernetes 的部署文件（例如 k8s/frontend-deployment.yaml）里，同样会构建并使用这个自定义镜像（通常通过 GitHub Actions 构建后推送到 GHCR）。Pod 里的容器镜像就是基于 Python 的这个轻量级服务。

🤔 为什么选择这种方式？

• 极简：不需要额外配置 Nginx 或学习其配置语法，非常适合展示型项目。

• 轻量：python:alpine 镜像非常小，启动快。

• 统一技术栈：整个项目都使用 Python，前端也用 Python 启动，保持技术栈一致性，便于维护。

📂 如果你希望换用专业的 Web 服务器

虽然项目没有用，但如果你在实际生产环境中想用 Nginx 来提供前端服务，也完全可以。你只需要：

这个项目保留了足够的灵活性，你可以自行调整。

🔍 如何自行验证

你可以在本地克隆项目后，查看以下文件来确认：

• camp-web-frontend/Dockerfile —— 确认基础镜像和启动命令。

• docker-compose.yml —— 确认前端服务的 build 和 image 字段。

• k8s/ 目录下的部署文件 —— 查看前端 Pod 使用的容器镜像地址。

        总的来说，这个项目用最轻量的 Python 内置服务器来托管前端，省去了引入独立 Web 服务器的复杂度，让你能够专注于 Kubernetes 和微服务的核心学习目标。