前端通过service名称（如backend-service）访问后端，需确保同namespace、dns可解析、selector匹配；nginx代理配置正确、健康探针就绪、镜像版本固定、secret正确引用。
kubectl apply 一条命令就能把前后端跑起来，但前提是镜像已就绪、YAML写对、网络连通——否则会卡在 ImagePullBackOff、CrashLoopBackOff 或服务间调不通。
怎么让前端容器访问后端服务？
别在前端代码里硬写 http://192.168.10.81:8080/api，K8s里应该用 Service 名称 + 端口。比如后端 Service 定义为 name: backend-service，前端 Nginx 配置里就写 proxy_pass http://backend-service:8080;。
关键点：
- 前后端必须在同一个
Namespace，或使用backend-service.default.svc.cluster.local全限定名 - Nginx 容器内要能 DNS 解析到该 Service，验证方式：
kubectl exec -it <frontend-pod> -- nslookup backend-service</frontend-pod> - 后端 Service 的
selector必须和后端 Pod 的labels完全匹配，一个字母都不能错 - 如果用 Ingress 暴露前端，后端仍需 ClusterIP Service，Ingress 不直接转发到 Pod
Deployment 和 Service YAML 怎么写才不踩坑？
常见错误是 Deployment 没配 readinessProbe，导致流量打到还没启动完的 Pod；或者 Service 的 targetPort 写成容器外暴露端口（如 8080），实际容器只监听 8081。
建议写法：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 后端
Deployment至少加readinessProbe：HTTP GET/actuator/health（Spring Boot）或自定义健康接口，初始延迟设为 10–30 秒 -
Service的port是集群内其他服务访问时用的端口（比如 80），targetPort必须等于容器实际监听端口（比如 8080） - 前端 Nginx 镜像不要用
latest标签，固定为v1.25.4这类语义化版本，避免镜像漂移 - 所有资源加
namespace: prod字段，别依赖默认命名空间，防止误操作污染default
为什么前端页面能打开，但 API 调用 502？
这基本不是 K8s 配置问题，而是 Nginx 容器内部代理配置没生效。常见原因：
- Nginx 配置挂载进容器后权限不对，
nginx.conf文件属主不是nginx用户，导致 reload 失败 - ConfigMap 挂载路径覆盖了原
/etc/nginx/conf.d/default.conf，但没删掉自带的include /etc/nginx/conf.d/*.conf;，造成配置冲突 - 前端构建时用了相对路径（
public/api），但 Nginx location 没做 rewrite，请求发到了/api/login而不是/backend/api/login - 后端 Service 存在，但
endpoint为空：kubectl get endpoints backend-service返回空，说明 selector 没匹配上任何 Pod
私有镜像仓库登录失败怎么办？
报错 Failed to pull image "...": rpc error: code = Unknown desc = failed to pull and unpack image...，大概率是 imagePullSecrets 没配或配错。
检查步骤：
- 确认 Secret 已创建：
kubectl create secret docker-registry regcred --docker-server=https://harbor.example.com --docker-username=admin --docker-password=xxx - Deployment 中引用位置必须在
spec.template.spec下，不是spec顶层：imagePullSecrets: [{name: regcred}] - Harbor 项目权限要给对应账号分配
pull权限，不能只建项目不授权 - 如果用的是自签名证书的 Harbor，所有节点的 containerd 配置里得加
insecure_skip_verify: true，否则拉镜像直接拒绝
真正卡住人的从来不是“怎么部署”，而是 “为什么这个 Pod 一直 ContainerCreating” 或 “为什么 curl service 名称超时”。这些细节藏在 kubectl describe pod 的 Events 里、kubectl logs 的启动日志里、以及 kubectl get endpoints 的输出里——别跳过它们。
