Nginx在容器化环境中需通过Dockerfile构建镜像并由Kubernetes Ingress路由流量：Dockerfile应指定稳定基础镜像、合理覆盖配置、正确放置静态资源；K8s中Service（ClusterIP）负责内部通信，Ingress则定义外部路由规则，须确保Pod就绪、Endpoint正常、Ingress Controller已部署且host匹配。
在容器化环境中，Nginx 通常作为静态资源服务或反向代理网关运行。它的部署不是孤立的，而是围绕两个核心环节展开：一是用 Dockerfile 打包成可复用、环境一致的镜像；二是通过 Kubernetes Ingress 将外部流量精准路由到该镜像启动的 Pod。关键不在于“能不能跑”，而在于配置是否可维护、网络是否通、路由是否可控。
Dockerfile 要写清楚三件事
一个生产可用的 Nginx 镜像，Dockerfile 必须明确指定基础镜像、配置文件和内容路径：
-
选稳定基础镜像：优先用
nginx:1.22-alpine或nginx:stable-alpine，体积小、更新节奏可控，避免直接用:latest引入不可预期变更； -
覆盖默认配置：用
COPY nginx.conf /etc/nginx/nginx.conf替换整个主配置，或更推荐COPY nginx.conf /etc/nginx/conf.d/default.conf，只覆盖 server 块，保留官方全局设置； -
静态资源放对位置：前端文件统一复制到
/usr/share/nginx/html/，若需多站点或子路径，可通过挂载卷或 ConfigMap 在 K8s 层动态注入，Dockerfile 里不硬编码路径。
K8s 中 Service 和 Ingress 的分工要分清
Service 是集群内部通信的抽象，Ingress 是对外暴露的入口规则。两者配合才能让 Nginx 正常被访问：
-
Service 类型建议用 ClusterIP：Nginx Pod 本身不需要被节点外直连，只需供 Ingress controller 发起请求，所以
type: ClusterIP更安全； -
Ingress 对象必须指向 Service 名称和端口：例如
serviceName: nginx-service、servicePort: 80，不能写 Pod IP 或容器端口； -
确保 Ingress Controller 已就绪：单独部署
ingress-nginx-controller是前提，它才是真正运行 Nginx 进程并加载 Ingress 规则的组件，不是你自己的 Nginx Deployment。
常见映射失败的几个检查点
请求进不来或 502/503，往往卡在链路某一层：
-
Pod 是否 Ready：执行
kubectl get pod -l app=nginx-frontend，确认状态为Running且READY列是1/1； -
Service 能否解析到 Pod：运行
kubectl get endpoints nginx-service，输出中应有实际 IP+端口，为空说明 selector 标签不匹配； -
Ingress 规则是否生效：查看
kubectl describe ingress nginx-ingress，关注Address字段是否已分配，以及 Events 中有无 “Successfully added” 类提示； -
域名与 host 匹配是否正确：Ingress 中写的
host: app.example.com，测试时 curl 必须带-H "Host: app.example.com"或配置本地 hosts，否则可能路由到 default backend。
