Service存在的核心价值

解决Pod动态性问题（服务发现）

• 动态IP困境：Pod每次重建都会分配新IP，无法直接依赖
• 服务发现机制：Service提供稳定的虚拟IP（VIP）和DNS名称
• 自动关联：通过Label Selector动态关联后端Pod集合

真实场景：某微服务架构包含50个Pod实例，每秒重建2-3个Pod。直接访问Pod IP导致30%请求失败，引入Service后失败率降至0.01%。

流量分发策略（负载均衡）

生产案例：某游戏平台使用sessionAffinity: ClientIP配置，使玩家会话始终路由到相同游戏实例，解决了跨实例状态同步问题。

Pod与Service的标签关联机制

核心关系图解

关系说明：Service通过Label Selector仅关联匹配标签的Pod（如app=nginx）

  graph LR
S[Service] -->|Label Selector| P1(Pod: app=nginx<br>env=prod)
S -->|Label Selector| P2(Pod: app=nginx<br>env=prod)
S -->|Label Selector| P3(Pod: app=nginx<br>env=prod)
P4(Pod: app=mysql<br>env=prod) -.-> S
  

标签匹配深度解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Service定义示例
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx     # 必须匹配
    env: prod      # 必须匹配
    tier: frontend # 必须匹配
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

诊断命令：

1
2
3
4
5

# 检查Service选择器
kubectl describe svc nginx-service | grep -i selector

# 验证Pod标签匹配
kubectl get pods -l 'app=nginx,env=prod,tier=frontend' --show-labels

常用Service类型

1. ClusterIP（默认类型）

• 特点：集群内部虚拟IP，不暴露到外网

• 典型场景：微服务间内部通信

• YAML示例：

  1 2 3 4 5 6 7 8 9 10 11

  apiVersion: v1 kind: Service metadata: name: internal-api spec: type: ClusterIP # 可省略（默认类型） selector: app: payment-service ports: - port: 8080 targetPort: 80

2. NodePort

• 特点：通过节点IP+静态端口暴露服务

• 端口范围：30000-32767（可自定义）

• 访问方式：<NodeIP>:<NodePort>

• 架构图：

  1 2 3

  外部用户 → Node1_IP:31000 → Service → Pod ↗ ↓ 或 ↘ Node2_IP:31000 → Service → Pod

端口映射详解

3. LoadBalancer

• 特点：集成云平台负载均衡器（AWS ELB, GCP LB等）
• 工作流程：
  1. 创建Service时自动申请云LB
  2. 云平台配置公网IP和转发规则
  3. LB将流量分发到各Node的NodePort
• 适用场景：生产环境公网访问入口

4. ExternalName

• 特点：提供CNAME别名映射

• 典型场景：访问集群外部服务

  1 2 3 4 5 6 7

  apiVersion: v1 kind: Service metadata: name: external-db spec: type: ExternalName externalName: production.db.example.com

  访问方式：ping external-db.default.svc.cluster.local 解析为 production.db.example.com

类型对比决策表