在Kubernetes（简称K8s）的生态中，Pod是最小的部署单元，但Pod存在一个天然的"痛点"------生命周期短暂，IP地址会随着Pod的创建、销毁而动态变化。如果直接通过Pod IP访问应用，稳定性根本无法保障。这时候，Service就应运而生了。
本文将从"为什么需要Service"出发，逐步深入讲解Service的核心概念、工作原理、常见类型及实战配置，帮你彻底搞懂Service在K8s集群中的作用和使用方式。
一、为什么需要Kubernetes Service？
要理解Service的价值，首先要明确Pod的局限性：
-
IP动态变化：Pod重启、重建（如滚动更新、节点故障）后，IP会重新分配，客户端无法固定依赖这个IP；
-
负载均衡缺失：多副本Pod部署时，客户端需要自己实现请求分发逻辑，无法高效利用多副本提升并发能力；
-
网络隔离与访问控制：直接暴露Pod到集群外存在安全风险，需要一层"中间层"统一管理访问规则。
Service的核心作用就是解决上述问题：它为一组具有相同功能的Pod提供一个固定的访问入口（ClusterIP），并通过标签选择器（Label Selector）关联Pod，实现请求的负载均衡和Pod的动态替换无感。
核心总结：Service是Pod的"稳定代理"，屏蔽了Pod的动态变化，提供统一、可靠的访问方式。
二、Service核心概念与工作原理
2.1 核心组件
一个完整的Service由以下关键部分组成：
-
标签选择器（Label Selector） ：Service通过Label关联Pod，只有带有对应标签的Pod才会被纳入Service的管理范围。例如，标签为
app: nginx的Pod，会被匹配selector: {app: nginx}的Service关联； -
ClusterIP：Service在集群内部的固定虚拟IP，是Service的核心访问入口。ClusterIP仅在集群内部可访问，外部无法直接访问；
-
端口映射（Ports）：定义Service的端口与Pod容器端口的映射关系，包括：
-
port：Service暴露的端口（集群内部访问时使用）；
-
targetPort：Pod容器中应用实际监听的端口（必须与容器内应用端口一致）；
-
nodePort（仅NodePort类型）：集群节点暴露的端口（外部访问时使用）；
-
containerPort：容器内部应用的端口（在Pod定义中指定）。
-
-
Endpoints：Service自动维护的Pod访问列表，记录了关联Pod的IP和targetPort。当Pod动态变化时，Endpoints会自动更新，确保Service始终能指向可用的Pod。
2.2 工作流程
Service的工作流程可以简化为以下几步：
-
用户创建Service，指定标签选择器和端口映射；
-
K8s控制器（Endpoint Controller）根据标签选择器匹配Pod，生成并维护Endpoints列表；
-
当客户端访问Service的ClusterIP:port时，请求会被K8s的网络插件（如Calico、Flannel）转发到Endpoints中的某个Pod的IP:targetPort（默认采用轮询负载均衡策略）；
-
若Pod发生销毁、重建或扩容缩容，Endpoints会实时更新，Service无需任何配置修改，客户端访问不受影响。