Kubernetes通过Service和Ingress协同实现外部流量转发：Service提供内部服务发现与负载均衡，Ingress负责对外暴露和智能路由；Service有NodePort、LoadBalancer、ClusterIP+kubectl proxy三种暴露方式；Ingress需配合Ingress Controller（如Nginx）使用，处理HTTP/HTTPS路由规则，并依赖Service暴露自身。
Kubernetes 将外部流量转发到集群内部，核心是通过 Service 和 Ingress 两层抽象协同完成的：Service 提供内部服务发现与负载均衡，Ingress 则负责对外暴露和智能路由。单纯靠 Service 可以实现基础访问，但要支持域名、路径、HTTPS 等生产级能力，必须引入 Ingress。
用 Service 暴露服务的三种常用方式
Service 是 Kubernetes 中最基础的服务暴露机制，类型决定流量如何从外部抵达：
-
NodePort：在每个节点的固定端口（如 30080）上开放服务，外部通过
<NodeIP>:<NodePort>访问。适合测试或小规模部署，但端口范围受限（30000–32767），且无法做域名/路径区分。 - LoadBalancer：云平台（如 AWS、阿里云）自动创建外部负载均衡器，并将流量转发到后端所有节点的 NodePort。最终由 kube-proxy 的 IPVS/iptables 规则将请求导向目标 Pod。需云环境支持，成本较高。
-
ClusterIP + kubectl proxy：仅限调试。运行
kubectl proxy --port=8080后，本地可访问http://localhost:8080/api/v1/namespaces/default/services/<svc-name>:<port>/proxy/。不适用于真实业务场景。
Ingress 是面向 HTTP/HTTPS 流量的标准入口
Ingress 不是服务本身，而是一组路由规则（YAML 定义）+ 执行这些规则的控制器（Ingress Controller）。它解决的是“同一个 IP 怎么分发到多个服务”的问题：
- 你定义一条规则：当 Host 是
shop.example.com、Path 是/api时，转发给名为api-service的 Service；Path 是/web时，转发给web-service。 - Ingress Controller（如 Nginx、Traefik）作为 Pod 运行在集群中，持续监听 API Server 中 Ingress 资源的变化，并动态更新其反向代理配置。
- Ingress Controller 本身需要先被外部访问——通常通过 LoadBalancer 或 NodePort 类型的 Service 暴露出来，形成“入口的入口”。
实际流量路径：从用户请求到 Pod
一次典型 HTTPS 请求的完整链路如下：
- 用户访问
https://blog.example.com/posts→ DNS 解析到云厂商提供的公网负载均衡器（如 ALB）IP； - 负载均衡器终止 TLS，将 HTTP 请求转发给后端一组运行 Nginx Ingress Controller 的 Pod（这些 Pod 通过 LoadBalancer 或 NodePort Service 暴露）；
- Ingress Controller 根据 Host 和 Path 匹配规则，把请求代理到
blog-service这个 ClusterIP Service； - 集群内每个节点上的 kube-proxy 已根据该 Service 的 selector 自动维护了 IPVS 规则，将请求直接转发到匹配标签的某个 Pod 的 IP 和端口；
- Pod 内容器接收并处理请求。
关键注意事项
部署前必须确认几个前提条件是否满足：
- Ingress Controller 必须已安装并正常运行（如
nginx-ingress-controller的 Deployment 和对应 Service 已就绪）； - Ingress 资源中引用的 Service 名称、端口、命名空间必须准确无误；
- 若使用自定义域名，DNS A 记录需指向 Ingress Controller 所在 Service 的外部 IP（LoadBalancer 的 EXTERNAL-IP 或 NodePort 节点的公网 IP）；
- HTTPS 证书可通过 Ingress 的
tls字段挂载 Secret，或由 Ingress Controller（如 Nginx）自动集成 Let’s Encrypt。
