一、Service 的本质
Service 是 K8s 里一种“抽象资源”，它为一组功能相同的 Pod 提供一个固定的访问入口，并自动做负载均衡。
固定入口 | Pod 的 IP 是临时的（重启就变），Service 的 IP（ClusterIP）是永久的 |
服务发现 | 你不需要知道 Pod 的真实 IP，只要访问 Service 的名字或 IP 就行了 |
负载均衡 | 访问 Service 的请求会被自动分发到它后面的多个 Pod 上 |
二、Service 的 4 种类型（type）
type | 访问范围 | 谁分配 IP | 适用场景 |
|---|
ClusterIP（默认） | 仅集群内部 | K8s 自动分配虚拟 IP | 微服务之间互相调用（登录服 → 游戏服） |
NodePort | 集群外可通过 节点IP:固定端口 访问 | K8s 在每台节点开端口（30000-32767） | 测试/演示，临时让外网访问 |
LoadBalancer | 公网通过云厂商 LB 访问 | 云厂商分配公网 IP | 生产环境公网入口（游戏网关） |
ExternalName | 把集群外服务映射成集群内 Service | 无 IP，返回 CNAME 域名 | 访问外部数据库/第三方 API |
三、Service 和 Pod 是怎么关联的？（核心机制）
Service 不直接绑定 Pod，而是通过 标签选择器（selector） 动态关联。
yaml
apiVersion: v1
kind: Service
metadata:
name: game-service
spec:
selector:
app: game-server # ← 找所有带这个标签的 Pod
ports:
- port: 80
targetPort: 8080
四、Service 的负载均衡是怎么实现的？（kube-proxy）
当客户端访问 Service 的 ClusterIP 时，流量实际上是被 kube-proxy 组件拦截并转发的。
两种模式：
模式 | 原理 | 特点 |
|---|
iptables（默认） | 在 Linux 内核的 iptables 表里写 NAT 规则，随机选一个后端 Pod | 稳定，但规则量大了（几万条）会变慢 |
IPVS（高性能） | 基于 Linux 内核的 IPVS 模块，专门为负载均衡设计 | 性能极高，支持轮询、最少连接等多种算法，大厂首选 |
五、Service 的访问方式（3 种）
访问方式 | 说明 | 示例 |
|---|
通过 Service 名（集群内） | 集群内的 Pod 直接使用 Service 名称访问，由 K8s DNS（CoreDNS）解析 | http://game-service:80
|
通过 ClusterIP（集群内） | 直接访问 Service 的虚拟 IP | http://10.96.100.200:80
|
通过 NodePort/LoadBalancer（集群外） | 外部用户通过节点 IP + NodePort 或云 LB 的公网 IP 访问 | http://192.168.1.100:31560
|
六、Ingress vs Service
对比维度 | Service | Ingress |
|---|
工作层级 | 4 层（TCP/UDP） | 7 层（HTTP/HTTPS） |
负载均衡 | 四层转发（IP + 端口） | 七层路由（域名 + URL 路径） |
访问范围 | 主要处理集群内部流量 | 主要处理集群外部流量（公网） |
是否支持 HTTPS | ❌ 不直接支持 | ✅ 支持（统一配置 SSL 证书） |
路由能力 | 只能按端口转发 | 可按域名/路径精细路由 |
适用场景 | 微服务内部互调 | Web 服务/API 网关入口 |
总结一句话：
Service 管“内部互找”（东西流量），Ingress 管“外部来玩”（南北流量）。
评论区