在 Kubernetes 中，应用通常以 Pod 的形式运行。但仅仅完成部署还不够，更关键的是如何让集群内外的用户稳定访问这些服务。为了解决访问入口、服务发现与流量分发等问题，Kubernetes 提供了 Service 和 Ingress 两类核心能力。
简单理解，Service 和 Ingress 都与流量接入有关。当前者主要负责将请求转发到后端 Pod，后者则更适合处理集群外部的 HTTP/HTTPS 访问入口、域名路由以及统一暴露服务。
一、Service 是什么
Pod 是承载应用的最小运行单元，理论上可以直接通过 Pod IP 访问应用。但 Pod 是有生命周期的，一旦出现异常被重建，IP 地址往往也会改变。因此，直接依赖 Pod IP 并不是稳定的访问方式。
Service 的作用，就是把一组 Pod 统一抽象为一个稳定的访问入口。客户端只需要访问 Service 的地址，Kubernetes 就会自动把流量转发到后端可用的 Pod。
Service 的实现并不是独立完成的，它依赖每个 Node 节点上的 kube-proxy 组件。这个组件会监听 Service 和相关 Endpoint 的变化，并在节点上生成相应的转发规则。
当创建 Service 后，相关信息会通过 API Server 写入存储系统。kube-proxy 监听到这些变化后，会在节点上生成对应的流量转发策略，从而让请求能够正确到达后端 Pod。
理解了这一点，就能明白 Service 本质上是 Kubernetes 提供的一层稳定访问抽象，而真正的流量转发由节点上的网络规则完成。
二、kube-proxy 的三种工作模式
kube-proxy 常见的工作模式有三种：Userspace、iptables 和 IPVS。它们的核心目标都是把访问 Service 的请求分发到后端 Pod，但实现方式与性能表现不同。
1. Userspace 模式
在 Userspace 模式下，kube-proxy 会为每个 Service 创建一个监听端口。当请求访问 Cluster IP 时，iptables 会先把请求重定向到 kube-proxy 监听的端口，再由 kube-proxy 根据负载均衡算法挑选一个 Pod 建立连接。
这种模式实现稳定，但因为数据在内核空间和用户空间之间多次拷贝，转发效率相对较低。
2. iptables 模式
在 iptables 模式下，kube-proxy 不再直接承担转发工作，而是为每个 Service 和后端 Pod 创建对应的 iptables 规则。请求到达后，会直接根据规则转发到目标 Pod。
这种方式比 Userspace 更高效，但负载均衡策略灵活性有限，而且当后端 Pod 不可用时，重试能力较弱。
3. IPVS 模式
IPVS 模式与 iptables 类似，都是由 kube-proxy 根据 Service 和 Pod 变化生成转发规则。但 IPVS 在性能和扩展性上通常更好，同时支持更多负载均衡算法，因此在生产环境中较为常见。
三、IPVS 模式的简单实践
为了观察 Service 在 IPVS 模式下的工作方式，可以先准备一份资源清单，其中上半部分用于创建 Pod 控制器，下半部分用于创建 Service。
资源创建完成后，Service 会为后端 Pod 提供统一访问入口。
接着可以通过查看 IPVS 规则，确认流量分发策略是否已经生效。通常能看到某个 Service 地址后面挂载了多个 Pod 实例，kube-proxy 会按设定的算法把请求分发出去，例如轮询。
当 Service 建立后，对应规则会同步到集群中的各个节点，因此在任意节点都可以通过该入口访问服务。
需要注意的是，若节点未安装 IPVS 所需内核模块，kube-proxy 可能会自动退回到 iptables 模式。
如果要启用 IPVS，可以编辑 kube-proxy 的配置：
kubectl edit cm kube-proxy -n kube-system
保存退出后，重建 kube-proxy 相关 Pod，让配置生效。之后再查看 IPVS 规则即可确认当前模式。
四、Service 的基本使用方式
创建 Deployment 和 Service 之后，通常可以通过以下方式访问服务：
Service IP + targetPort
Node IP + nodePort
不过，Service 并不只有一种形式。它包含多种类型，适用于不同访问场景。
五、ClusterIP 类型
ClusterIP 是最常见的 Service 类型，也是默认类型。它会在集群内部生成一个虚拟 IP，供集群内其他服务访问。
下面是 ClusterIP 类型 Service 的资源清单示意：
创建完成后，可以通过 ClusterIP 加端口在集群内部访问该服务。
此时再查看 IPVS 规则，就可以看到该 Service 已经把流量关联到后端多个 Pod。
如果使用 describe 查看 Service 详情，会发现一些重要字段，例如 Endpoints 和 Session Affinity。
1. Endpoints 是什么
Endpoints 是 Kubernetes 中的一个资源对象，用于记录某个 Service 当前对应的 Pod 访问地址。它通常是根据 Service 的 selector 自动生成的。
可以把它理解为 Service 和 Pod 之间的连接清单：Service 定义了统一入口，Endpoints 负责列出真实可转发的目标地址。
2. 负载分发机制
当一个 Service 对应多个 Pod 时，Kubernetes 会把流量分发到这些 Pod 上。为了便于观察，可以分别修改 3 个 Pod 中的页面内容，然后重复访问 Service，查看返回结果是否发生变化。
# pod01 Pod01 : IP – 10.244.1.73 # pod02 Pod01 : IP – 10.244.1.73 # pod03 Pod03 : IP – 10.244.2.63
随后多次执行访问请求，就能看到请求被分配到了不同 Pod。
这种现象本质上就是负载均衡。默认情况下，Service 的流量分发策略通常由 kube-proxy 决定，常见表现包括随机或轮询。
在查看 IPVS 规则时，如果看到 RR 字段，通常表示当前使用的是轮询策略。
3. Session Affinity 会话保持
有些场景下，希望同一个客户端发出的请求始终落到同一个 Pod，例如依赖本地会话状态的应用。这时就可以使用 Session Affinity。
只需要在 Service 的 spec 中增加以下配置：
sessionAffinity: ClientIP
重新查看规则后，可以发现分发策略已经发生变化。
继续测试访问结果，就可以验证同一客户端是否始终命中同一个后端 Pod。
需要特别注意，ClusterIP 类型的 Service 仅能在集群内部访问，不能直接作为外部浏览器入口使用。
六、Headless Service
并不是所有场景都适合由 Kubernetes 自动完成负载均衡。有些系统希望直接感知后端 Pod 列表，或者自行决定请求分发逻辑，例如数据库集群、分布式中间件、状态服务等。
为此，Kubernetes 提供了 Headless Service。它不会分配 ClusterIP，而是通过 DNS 直接返回后端 Pod 的地址，让客户端自行选择连接目标。
Headless Service 适合那些需要更细粒度服务发现能力，而不依赖统一虚拟 IP 转发的场景。
七、Ingress 的作用
如果说 Service 主要解决的是服务在集群内部或节点级别的暴露问题，那么 Ingress 更适合处理集群外部访问入口。
在没有 Ingress 时，通常需要为每个服务单独暴露 NodePort 或 LoadBalancer，这样不仅管理复杂，也不利于统一配置域名、路径和 HTTPS。
Ingress 的核心价值在于：可以把多个服务统一挂到一个入口之下，并按域名或 URL 路径将请求转发到不同的 Service。
常见使用场景包括：
同一个域名下按路径转发到不同服务
不同域名转发到不同业务模块
统一配置 HTTPS 证书
为外部访问提供更清晰、可维护的入口结构
需要注意，Ingress 本身只是规则定义，真正执行转发工作的还需要 Ingress Controller，例如 NGINX Ingress Controller。
八、Service 与 Ingress 的关系
可以把二者的职责简单理解为：
Service：负责把流量送到一组 Pod
Ingress：负责把外部请求按规则转发到不同 Service
通常的调用链路是：外部用户访问 Ingress，Ingress 再根据域名或路径把请求转发到目标 Service，Service 再把流量分发到后端 Pod。
九、总结
在 Kubernetes 中，Service 和 Ingress 是服务访问体系中的关键组件。
Service 解决的是 Pod 地址不稳定的问题，为一组 Pod 提供统一、稳定的访问入口；同时依赖 kube-proxy 在节点上生成转发规则，并通过 Userspace、iptables、IPVS 等模式实现流量分发。
在实际使用中，ClusterIP 适合内部访问，Headless Service 适合需要直接暴露 Pod 地址的服务发现场景，而 Ingress 则更适合对外提供统一的 HTTP/HTTPS 访问入口。
如果想真正掌握 Kubernetes 的服务访问机制，理解 Service、Endpoints、负载均衡策略以及 Ingress 之间的关系，是非常重要的一步。
