[特殊字符] 第二篇：班级留言板 K8s 部署实践（下）—— 服务暴露与滚动更新

一、背景与目标

承接上篇：上篇完成了镜像构建、节点分发和 Pod 启动，但 Pod 运行在集群内部，外部无法访问。

一句话说清：验证 Kubernetes Service 如何将应用对外暴露，以及 Deployment 的滚动更新与回滚机制。

本篇重点：

Service（NodePort）配置与访问验证
多项目共存时的端口规划
滚动更新与快速回滚
ConfigMap 动态更新

二、环境说明

与上篇一致，不再赘述。

端口规划：由于集群中已有 IoT 管理系统（前端 30081，后端 30786），新项目需避开这些端口：

项目	前端端口	后端端口
IoT 管理系统（已有）	30081	30786
班级留言板（新）	30082	30787

三、操作步骤

第一步：准备 Service 配置

在 Service 的 YAML 文件中指定 type: NodePort 和 nodePort 端口号，确保不与其他项目冲突。

前端 Service 配置类似，nodePort 为 30082。

第二步：部署并验证

复制代码

kubectl apply -f k8s/api-service.yaml
kubectl apply -f k8s/frontend-service.yaml
kubectl get svc -n message-board

📸 截图 6：Service 列表

第三步：浏览器访问验证

服务	URL	预期结果
前端页面	http://192.168.116.168:30082	显示留言板界面
后端健康检查	http://192.168.116.168:30787/health	`{"status":"ok"}`
留言列表	http://192.168.116.168:30787/messages	显示默认留言

四、滚动更新与回滚

滚动更新

当需要更新应用时（比如修改前端页面样式），重新构建新版本镜像后，执行：

复制代码

# 构建新版本（v2）并分发到 node2
docker build -t message-frontend:v2 ./frontend
docker save -o message-frontend-v2.tar message-frontend:v2
scp message-frontend-v2.tar root@192.168.116.170:/root/message-board/
ssh root@192.168.116.170 "docker load -i /root/message-board/message-frontend-v2.tar"

# 更新 Deployment 中的镜像版本
kubectl set image deployment/message-frontend message-frontend=message-frontend:v2 -n message-board

# 查看更新进度
kubectl rollout status deployment/message-frontend -n message-board

回滚操作

如果新版本有问题，可以快速回滚到上一个版本：

复制代码

# 查看历史版本
kubectl rollout history deployment/message-frontend -n message-board

# 回滚
kubectl rollout undo deployment/message-frontend -n message-board

# 确认回滚状态
kubectl rollout status deployment/message-frontend -n message-board

回滚操作会重新创建 Pod，恢复到上一个版本的镜像。

五、问题排查补充

在浏览器访问时，如果前端页面能打开但留言列表加载失败，通常有两种情况：

后端 Pod 未正常运行 ：检查 kubectl get pods -n message-board，确保后端 Pod 处于 Running 状态
前端 ConfigMap 中 API 地址配置错误 ：检查 ConfigMap 中的 API_BASE_URL 是否指向正确的 Service 地址

复制代码

# 查看 ConfigMap 内容
kubectl describe configmap frontend-config -n message-board

# 如果需要修改
kubectl edit configmap frontend-config -n message-board
# 编辑后重启前端 Pod 使配置生效
kubectl rollout restart deployment/message-frontend -n message-board

六、观察与解读

Service 的三种类型对比

Service 类型	访问范围	适用场景
ClusterIP（默认）	集群内部 IP 访问	内部服务互相调用
NodePort	节点 IP + 固定端口访问	测试环境或开发调试
LoadBalancer	外部 IP 访问（需云厂商支持）	生产环境对外服务

实训环境选择 NodePort 是最合适的------无需云厂商支持，直接通过节点 IP 加端口即可访问。

滚动更新的工作原理

执行 kubectl set image 后，Deployment Controller 会逐步用新版本 Pod 替换旧版本 Pod。默认配置下，先启动一个新 Pod，等它 Ready 后再终止一个旧 Pod，以此类推。这个过程保证了服务始终可用，不会出现全部 Pod 同时重启导致的停机窗口。

七、完整实验总结

两篇回顾

阶段	核心内容	关键收获
上篇（容器化）	Dockerfile 编写、镜像构建、跨节点分发	离线环境下的镜像管理策略、Pod 启动失败排查思路
下篇（编排与访问）	Service 暴露、滚动更新、ConfigMap 配置	端口规划、零停机更新、配置与镜像解耦

核心感悟

Docker 解决了什么：环境一致性。同样的镜像在任何节点运行，结果完全一致。
Kubernetes 解决了什么：大规模容器编排。声明式 API 让部署、扩缩容、更新都变得标准化和自动化。
云原生的理念：不可变基础设施 + 配置分离，让应用更易于管理和演进。