第六章 Kubernetes Service 章节前置回顾
上一章已讲解完官方预定义的Pod控制器，相关内容如下：
- ReplicaSet（RS）：保障Pod副本数量与期望值一致
- Deployment：基于RS管理Pod，提供声明式表达方式，支持滚动更新与回滚
- DaemonSet：保障每个节点有且仅有一个对应Pod运行，随集群节点扩容自动增加Pod
- Job：处理单次批处理任务
- CronJob：支持周期性创建Job完成批处理任务
- StatefulSet：需依赖存储实现数据持久化，本章暂不展开
本章Service学习规划
本章共分为4个部分：
- Service的概念与核心意义
- Service的工作原理与实验演示
- Endpoints（端点）：Service底层的关联对象
- 未就绪服务的暴露方案补充
1. Service概念与核心意义
1.1 微服务背景与痛点
传统单体架构存在多重问题：
- 代码耦合度高，后期功能迭代难以剥离
- 多人协作开发时代码冲突频发
- 单模块升级会影响全局服务，故障影响范围大
微服务架构将整体应用拆分为独立的小型模块，每个模块即为一个微服务，多个微服务组合形成完整业务能力，优势包括： - 不同团队可并行开发不同微服务模块，提升开发效率
- 单模块性能不足时可针对性扩容节点，提升资源利用率
- 单模块故障不会影响其他模块运行
但微服务部署在传统架构下面临挑战：若每个微服务单独配置负载均衡、分配机器，会导致机器数量激增，资源利用率极低，成本过高。
1.2 Service的定义与作用
Service是Kubernetes集群中用于暴露服务的核心资源对象，定义为Pod的逻辑分组+访问策略，通常对应一个微服务。
其核心工作逻辑：
- 通过标签选择器匹配符合要求的Pod，需同时满足两个条件：① 就绪探测（Readiness Probe）通过；② Pod标签匹配Service配置的标签选择器
- 被选中的Pod会被加入Service的负载均衡集群，对外提供统一的访问端点，实现负载访问
1.3 Service的必要性案例（Nginx+Tomcat场景）
传统架构下实现Nginx反向代理到多个Tomcat Pod的方案存在明显缺陷：
- 需手动在Nginx配置中写入所有Tomcat Pod的IP到upstream块，Pod故障重建后IP变更，新Pod无法自动加入负载队列
- 需额外编写脚本监听Pod变更、修改Nginx配置并重启Nginx生效，复杂度极高
引入Service后可完美解决该问题： - Service会自动维护后端Pod列表，故障未就绪的Pod会被自动踢出负载集群，新就绪的Pod会被自动加入
- Nginx仅需将反向代理目标配置为Service的IP即可，前后端完全解耦，Nginx对后端Pod的变更无感知
2. Service底层原理（三种代理模式演进）
Kubernetes中Service的底层实现依赖节点上的kube-proxy组件，随版本迭代共经历三代代理模式：
2.1 用户空间代理模式（K8s 1.0起，已废弃）
- 核心组件：API Server、kube-proxy
- 工作流程：
- 每个节点的kube-proxy监听API Server的Service变更事件
- 修改本机iptables规则实现流量分发
- 同时由kube-proxy代理客户端请求，转发给后端Pod并返回响应
- 缺点：kube-proxy同时承担规则修改和请求代理两个功能，请求规模较大时压力较高，功能耦合不利于稳定迭代
2.2 iptables代理模式（K8s 1.2起为默认模式，当前版本仍为默认）
- 核心组件：API Server、kube-proxy
- 工作流程：
- kube-proxy监听API Server的Service变更事件
- 仅将规则写入本机iptables，后续流量转发完全由iptables处理
- kube-proxy不再参与请求代理环节
- 优势：功能解耦，kube-proxy仅负责规则同步，压力更小，稳定性更高
2.3 IPVS代理模式（K8s 1.8.0起支持，性能更优但非默认）
- 底层基于Linux内核的LVS（四层负载均衡器），用IPVS规则替换iptables作为转发载体
- 工作流程：
- kube-proxy监听API Server的Service变更事件
- 将负载均衡规则转换为IPVS规则写入本机
- 客户端请求直接由IPVS负载均衡到后端Pod
- 优势：IPVS是专业的四层负载均衡方案，性能优于iptables模式
- 注意事项：IPVS模块需要内核开启，部分云厂商的云服务器会默认移除该模块（避免用户自建负载均衡，减少其LaaS服务购买），使用前需确认本机IPVS模块可正常加载，若支持加载建议切换为IPVS模式提升性能
3. 实验操作演示
视频中进行了代理模式验证实验，操作步骤如下：
- 创建Nginx Deployment：执行
kubectl create deployment my --image=nginx:1.0 - 扩容副本数：执行
kubectl scale deployment my --replicas=10，将副本数扩容至10 - 创建ClusterIP类型Service：执行
kubectl create service clusterip my --tcp=80:80，创建与Deployment同名的ClusterIP Service，端口映射为集群端口80对应Pod端口80 - 验证代理模式：执行
ipvsadm -l，当前无IPVS规则输出，确认当前集群默认使用iptables代理模式 - 后续计划：完成三种代理模式讲解后，演示如何将kube-proxy工作模式从iptables迁移到IPVS
AI 总结
Service是Kubernetes解决微服务访问、负载均衡、服务发现的核心资源对象，通过标签选择器自动维护后端就绪Pod列表，实现故障自愈与前后端解耦，大幅降低微服务部署与运维复杂度。其底层代理模式历经用户空间、iptables两代迭代后，当前默认使用iptables模式，IPVS模式作为性能更优的选项，在支持内核模块的场景下是更佳选择。