KnoAI 技术站

主题

第2章 为什么需要 Service ​

本章回答一个根本问题：Kubernetes 中为什么需要 Service？理解这一点，是掌握后续所有内容的基础。

2.1 Pod 直接通信的问题 ​

假设你有一个电商系统：

  • 前端服务需要调用用户服务
  • 用户服务需要调用订单服务
  • 订单服务需要调用数据库

如果这些服务都直接通过 Pod IP 互相访问，会发生什么？

问题1：Pod IP 不固定 ​

Pod 被销毁重建后 IP 会变。例如：

text
昨天：user-service Pod IP = 10.244.1.10
今天：user-service Pod IP = 10.244.2.15

前端服务如果写死了 http://10.244.1.10:8080，今天就访问不到了。

问题2：Pod 数量动态变化 ​

Deployment 的副本数可能随时变化：

text
高峰期：10 个 Pod
低谷期：2 个 Pod

调用方如何知道现在应该连哪几个 IP？

问题3：滚动更新时的短暂不可用 ​

应用升级时，旧 Pod 逐个被新 Pod 替换。如果调用方刚好连到一个正在终止的 Pod，就会失败。

问题4：负载无法均衡 ​

即使调用方维护了一个 Pod IP 列表，它还要自己实现负载均衡、健康检查、故障转移，这太复杂了。

2.2 Service 的引入 ​

Kubernetes 引入 Service，为一组 Pod 提供一个稳定的访问入口。

text
┌─────────────────────────────────────┐
│              Service                │
│      ClusterIP: 10.96.123.45        │
│      selector: app=web              │
└──────────────┬──────────────────────┘
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
   ┌──────┐ ┌──────┐ ┌──────┐
   │ Pod  │ │ Pod  │ │ Pod  │
   │10.244│ │10.244│ │10.244│
   │.1.10 │ │.1.11 │ │.1.12 │
   └──────┘ └──────┘ └──────┘

Service 做了三件事：

  1. 提供稳定 IP（ClusterIP）：不随 Pod 变化而变化。
  2. 通过 Label Selector 关联 Pod：自动发现匹配的后端。
  3. 提供负载均衡：将流量分发到多个后端 Pod。

2.3 把 Service 想象成公司总机 ​

analogy 快递公司：

  • Pod = 公司里的每个客服工位
  • Pod IP = 每个工位的分机号
  • Service = 公司总机系统
  • ClusterIP = 公司总机号码

客户只需要记住公司总机号码，总机会自动把电话转接给空闲的客服。即使某个客服下班了（Pod 被删除），总机也会转给其他客服。

2.4 Service 解决了什么问题 ​

问题Service 如何解决
Pod IP 不固定提供稳定的 ClusterIP 和 DNS 名称
Pod 数量变化通过 selector 自动更新后端列表
负载均衡kube-proxy 自动分发流量
滚动更新配合 readinessProbe，只把流量发给就绪 Pod
服务发现通过 DNS 名称访问，无需硬编码 IP

2.5 本章小结 ​

  • Pod 是动态、短命、IP 不固定的，不能直接作为稳定服务入口。
  • Service 为 Pod 组提供稳定 IP、自动发现和负载均衡。
  • Service 是 Kubernetes 内部服务通信的“交通枢纽”。

本章练习 ​

  1. 画一张图，展示没有 Service 时应用如何互相访问，以及有什么问题。
  2. 用自己的话解释：ClusterIP、selector、kube-proxy 分别解决什么问题？
  3. 思考：Service 本身是一个进程吗？它运行在哪里？