续：从 Docker Compose 到 Kubernetes（2）—— 服务优化与排错

加油打工人！

上篇回顾：完成了物联网管理系统在 K8S 上的部署，前后端正常运行，设备管理功能可用。但有一个问题：迁移只是完成了"跑起来"，生产环境还需要考虑资源控制和故障自愈。

本篇目标：给后端服务加上资源限制和健康检查。

一、配置资源限制

目的：防止容器耗尽节点资源，影响其他 Pod。

修改 Deployment ，在 containers 下添加：

yaml

复制代码

resources:
  requests:
    memory: "256Mi"
    cpu: "200m"
  limits:
    memory: "512Mi"
    cpu: "500m"

应用配置：

复制代码

kubectl apply -f iot-backend-deploy.yaml
kubectl rollout status deployment iot-backend

验证：

复制代码

kubectl describe pod $(kubectl get pod -l app=iot-backend -o jsonpath='{.items[0].metadata.name}') | grep -A3 "Limits\|Requests"

二、配置健康检查

目的：让 K8S 自动检测服务状态，挂掉时自动重启。

添加探针配置：

yaml

复制代码

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

验证：

复制代码

kubectl describe pod $(kubectl get pod -l app=iot-backend -o jsonpath='{.items[0].metadata.name}') | grep -A5 "Liveness\|Readiness"

三、配置后出现新问题

现象：配置完健康检查和资源限制后，浏览器无法进行设备增删改查。

排错思路：

1. 检查后端日志

复制代码

kubectl logs -l app=iot-backend --tail=50

后端启动正常，无报错。

2. 检查后端接口

复制代码

curl http://10.109.210.199:8080/device/list

返回正常数据，后端接口没问题。

3. 检查 Service Endpoints

复制代码

kubectl get endpoints iot-backend-svc

ENDPOINTS 有值，Service 能转发流量。

4. 浏览器直接访问后端

复制代码

http://192.168.116.168:30786/device/list

返回 ERR_CONNECTION_REFUSED。

5. 检查 Service 类型

复制代码

kubectl get svc iot-backend-svc

发现 Service 类型变成了 ClusterIP。

根本原因：重新 apply Deployment 时，连带修改了 Service 配置，导致后端 Service 从 NodePort 变回了 ClusterIP。

四、修复问题

将后端 Service 改回 NodePort 并固定端口：

复制代码

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: iot-backend-svc
spec:
  type: NodePort
  selector:
    app: iot-backend
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 30786
EOF

验证：

复制代码

curl http://192.168.116.168:30786/device/list

返回正常数据。

浏览器访问 http://192.168.116.168:30081，设备管理功能恢复。

五、验证健康检查生效

模拟后端故障：

复制代码

kubectl exec -it $(kubectl get pod -l app=iot-backend -o jsonpath='{.items[0].metadata.name}') -- pkill java

观察 Pod 自动重启：

复制代码

kubectl get pods -w

六、核心问题汇总

问题	原因	解决方案
配置后服务异常	Service 类型被覆盖为 ClusterIP	改回 NodePort 并固定端口
端口老变动	没指定 nodePort	YAML 中固定 nodePort

七、小结

从 Docker Compose 迁移到 Kubernetes，不只是把容器搬过来。资源限制 保障了多容器共存时的资源分配，健康检查实现了服务故障的自愈。这是 K8S 相比 Docker Compose 的核心能力差异。

配置过程中的 Service 类型被覆盖，也提醒了一件事：Deployment 和 Service 的配置应该分开管理，避免 apply 时互相影响。