小节前置说明
上一小节讲解了Service的底层工作原理，涵盖用户空间模式、iptables模式、IPVS模式三种实现逻辑，且已完成将集群默认的iptables模式切换为IPVS模式，获得更高的性能与稳定性。本小节核心讲解Service的4种工作模式（类型）的含义、特性、区别，以及相关组件协同、实验配置、IPVS工作模式等内容，核心原则为「不存在适用于所有场景的最优工作模式，需结合实际需求选择适配类型」。
Service的4种核心工作模式
1. ClusterIP（集群IP，默认类型）
- 定义：创建Service时若未指定类型，默认即为ClusterIP类型，是K8s Service最基础的工作模式
- 原理：自动为Service分配一个集群内部可访问的虚拟IP（VIP），自动将后端满足条件的Pod（就绪状态、标签选择器匹配）绑定到VIP对应的负载均衡集群中
- 核心价值：解决Pod IP动态变化的问题（如Deployment下Pod故障重建后IP会变更），避免硬编码Pod IP导致的配置失效
- 特性：后端Pod的IP、状态变更时，Service会自动更新负载均衡规则，对前端调用方完全透明无感知
- 示例场景：集群内部服务调用，如Nginx Pod反向代理Tomcat Pod的场景，Nginx仅需指向ClusterIP的VIP即可，无需关注后端Tomcat Pod的IP变化
2. NodePort（节点端口）
- 定义：在ClusterIP的基础上扩展，为Service在集群所有节点的物理网卡上绑定一个固定端口
- 端口规则：默认端口范围为30000~32767，可通过kube-proxy的启动参数自定义修改
- 原理：用户可通过「任意节点IP:NodePort端口」访问集群内部服务，流量最终会路由到ClusterIP的VIP，再负载到后端Pod
- 核心价值：解决ClusterIP仅集群内部可访问的问题，将集群内部服务暴露到集群外部
- 特性：集群所有节点都会绑定相同的NodePort，任意节点访问该端口均可正常转发到后端服务
- 示例场景：自建机房/私有云场景下临时对外提供服务，或开发测试环境需要快速暴露服务的场景
3. LoadBalancer（负载均衡，云环境专属类型）
- 定义：在NodePort的基础上进一步做高可用封装，是云服务商提供的「负载均衡即服务（LBaaS, Load Balance as a Service）」的落地实现
- 原理：
- 自建机房/私有云场景：需手动搭建IPVS集群实现高可用，避免单节点故障，用户访问IPVS的VIP，IPVS将流量转发到各节点的NodePort
- 云环境场景：直接调用云服务商的LB接口，由云服务商自动创建负载均衡实例并关联后端服务，集群的API Server（实际由kube-proxy发起调用）自动完成配置，无需手动搭建负载均衡集群
- 核心价值：解决NodePort的单节点故障问题，实现服务对外暴露的高可用
- 特性：仅云环境可用，非云环境下无云服务商提供LBaaS能力，无法使用该类型
- 示例场景：云上K8s集群生产环境对外提供服务，直接创建LoadBalancer类型Service即可获得云厂商提供的公网负载均衡能力
4. ExternalName（外部服务名）
- 定义：用于将集群外部服务引入集群内部，不基于IPVS实现流量转发，而是基于CoreDNS的DNS别名机制实现
- 原理：创建ExternalName类型的Service时，需指定外部服务的域名/IP，CoreDNS会为该Service生成一条固定格式的DNS解析记录：
<service-name>.<namespace>.svc.<cluster-domain>（默认集群域名为cluster.local）。集群内部Pod访问该域名时，CoreDNS会返回配置的外部服务地址，实现别名解析 - 核心价值：解决集群内部Pod访问外部服务时硬编码地址的问题，修改Service配置即可全局生效，无需重启Pod或重新打包镜像
- 特性：仅做DNS解析别名，不做流量转发；支持动态修改后端地址，对调用方完全透明
- 示例场景：集群内应用需要访问集群外部的传统数据库（如MySQL、Oracle，容器化支持尚不完善），或需要快速切换测试/生产环境的外部服务地址的场景
Service组件协同流程
Service的创建与规则落地需要多个K8s组件协同完成：
- 管理员通过
kubectl发起创建Service的请求 - 请求发送到集群的API Server，经过认证、校验后存储到etcd中持久化
- 集群每个节点上的kube-proxy监听API Server的Service配置变化
- kube-proxy将Service的配置落地为对应的负载均衡规则：
- 当前使用IPVS模式时，落地为IPVS规则
- 若使用默认iptables模式，落地为iptables防火墙规则
ClusterIP资源清单示例
以下是ClusterIP类型Service的YAML配置示例，核心字段说明：
apiVersion: v1
kind: Service
metadata:
name: tomcat-svc # Service名称
namespace: default # 所属命名空间
spec:
type: ClusterIP # 工作模式，不填写时默认即为ClusterIP
selector:
app: tomcat # 标签选择器，需匹配后端Pod的标签，要求是Pod标签的子集
ports:
- name: http # 端口名称
port: 80 # Service的集群端口，即集群内部访问Service的端口
targetPort: 80 # 后端Pod的真实业务端口
IPVS的核心工作模式
K8s使用IPVS作为Service的负载均衡实现时，IPVS本身支持4种调度模式，当前K8s集群默认采用NAT模式：
1. NAT模式（Network Address Translation，网络地址转换）
- 原理：所有流量（入站、出站）都需要经过IPVS调度器转发
- 优点：后端Pod的端口可以与Service的集群端口不一致，灵活性高
- 缺点：IPVS调度器本身会成为性能瓶颈，流量需要经过两次转发
- 适用场景：大部分通用场景，当前K8s默认采用该模式
2. DR模式（Direct Routing，直接路由）
- 原理：回程流量不需要经过IPVS调度器，直接由后端Pod返回给客户端
- 优点：IPVS调度器压力小，性能更高
- 缺点：后端Pod的端口必须与Service的集群端口一致；需要额外配置ARP响应和通告规则，网络配置相对复杂
- 适用场景：对性能要求高、网络环境可控的场景
3. 隧道模式（Tunnel Mode）
- 原理：通过IPIP隧道封装数据报文，实现跨物理网络的Pod集群调度
- 优点：可以跨物理网络组建虚拟Pod集群，不受底层网络限制
- 缺点：性能较低，需要做数据报文的二次封装和解封装，额外消耗CPU和带宽
- 适用场景：跨地域、跨网络的集群服务调度场景
4. fullnat模式
视频未展开讲解，暂不赘述。
AI 总结
本小节系统讲解了Kubernetes Service的4种核心工作模式：默认的ClusterIP用于集群内部服务发现与负载均衡，解决Pod IP动态变化的问题；NodePort通过绑定节点端口实现集群服务对外暴露；LoadBalancer是云环境下的高可用封装，无需手动搭建负载均衡集群；ExternalName基于CoreDNS别名机制实现集群外部服务的无缝引入。同时讲解了Service的组件协同流程、ClusterIP的资源清单写法，以及IPVS的NAT、DR、隧道三种核心工作模式，当前K8s集群默认采用IPVS的NAT模式实现Service的负载均衡能力，可根据业务场景和基础设施灵活选择适配的服务类型与IPVS工作模式。