K8s中Nginx Ingress Controller的Service/Ingress/ConfigMap区别

kind: Service 和 kind: Ingress 不属于同一种Kubernetes资源，二者定位、作用层级、生效逻辑完全不同。结合Nginx Ingress Controller的使用场景，三类关联资源的作用边界和核心区别如下：

1. kind: Service #

• 属于K8s四层（TCP/UDP）负载均衡抽象，核心作用是给一组动态调度、IP随时可能变化的业务Pod提供固定的访问入口，解决Pod IP漂移、多副本负载分发的问题。
• 常规作用范围是集群内部，即便是NodePort、LoadBalancer类型的Service，也只做四层端口层面的转发，无法识别HTTP/HTTPS协议里的域名、路径、请求头等七层特征。
• 在Nginx Ingress的流量链路里，Service是路由规则最终指向的后端实体：Nginx收到匹配规则的请求后，会先把流量转发给对应的Service，再由Service分发给后端实际运行业务的Pod。
• 举个实际场景：你部署了3个运行业务接口的Pod，创建名为api-svc的Service关联这3个Pod的8080端口，这个Service会分配到一个固定不变的ClusterIP，集群内所有组件访问这个固定IP+端口，就能轮询访问到后端3个业务Pod。

2. kind: Ingress #

• 属于K8s七层（HTTP/HTTPS）路由规则的声明式抽象，本身不具备任何流量转发能力，本质就是存在etcd里的一段规则配置，不会自己处理流量。
• 核心作用是定义外部进入集群的流量该怎么分发：比如哪个域名的请求要转给哪个后端、哪个路径对应哪个业务、要不要做SSL证书卸载、要不要按比例做灰度流量切分这类七层路由逻辑。
• 在Nginx Ingress Controller的工作流里，Ingress就是Controller的配置输入源：Controller会实时监听集群里所有Ingress资源的增删改，把这些规则翻译成Nginx可识别的配置文件，触发Nginx重载后让规则正式生效。
• 举个实际场景：你写一条Ingress规则，指定访问demo.example.com/user路径的请求全部转发给前面提到的api-svc，Nginx Ingress Controller拿到这条规则后，就会在自己的Nginx配置里新增对应的location匹配块，后续收到符合特征的请求就往api-svc转发。

3. kind: ConfigMap #

• 是K8s里通用的非敏感配置存储资源，本质是键值对格式的配置字典，和流量转发逻辑没有强绑定，存什么配置完全由使用它的组件决定。
• 在Nginx Ingress Controller场景下，ConfigMap用来给Controller本身（也就是实际跑Nginx进程的那个组件）做全局参数配置：比如全局请求超时时间、日志打印格式、是否开启gzip压缩、全局跨域规则、Nginx运行调优参数这类作用在整个Nginx实例上的配置，不是针对某一条业务路由的。
• 举个实际场景：你想把整个Nginx Ingress的客户端请求超时时间改成60秒，不需要重新构建Nginx镜像，只要把对应参数写在Controller关联的ConfigMap里，Controller会自动同步配置到Nginx运行参数中，不需要手动改Nginx配置文件。

边界快速区分 #

• Service：管集群内部四层流量怎么分发给Pod，是实际承接流量的后端
• Ingress：管外部七层流量怎么路由到对应Service，只是规则声明，不是实际的流量处理组件
• ConfigMap：管Nginx Ingress Controller自身的全局运行配置，和具体业务路由、后端转发逻辑没有直接关联

内容的提问来源于stack exchange，提问作者Jae