本文由 Claude-3.7-Sonnet 生成。
从裸机到容器：应对复杂性的演进
1. 物理服务器时代的困境
最初，应用程序直接部署在物理服务器上，导致：
- 资源利用率低下（一台服务器只运行一个应用）
- 环境一致性问题（”在我的机器上能运行”）
- 应用隔离性差
2. 虚拟机的改进
虚拟化技术出现，每台物理服务器可运行多个虚拟机：
3. 容器(Container)的革命
容器技术解决了关键痛点：
- 轻量级（共享宿主机OS内核）
- 快速启动（秒级）
- 可移植性强（构建一次，到处运行）
- 资源占用小
但问题出现了： 当容器数量增长，单机管理变得困难，集群管理更是挑战。
Kubernetes组件的逐步演进
1. Pod：为什么不直接使用容器？
容器本身有局限性：
- 单个容器难以满足应用的协作需求
- 需要将紧密关联的功能组合在一起
因此诞生了Pod：
- Pod是最小部署单元，包含一个或多个容器
- 共享网络命名空间和存储卷
- 同一Pod中的容器总是在同一节点上运行
- 适合边车(sidecar)模式，如日志收集、代理容器
2. ReplicaSet：确保可用性
Pod解决了部署问题，但如何确保高可用？
ReplicaSet应运而生：
- 自动维护指定数量的Pod副本
- 监控Pod状态，替换失败的Pod
- 实现应用的可扩展性
3. Deployment：应对变更
应用需要更新，但如何安全更新？
- 如何避免更新过程中的服务中断？
- 如何在出问题时回滚？
Deployment提供了解决方案：
- 管理ReplicaSet的版本更迭
- 实现无缝的滚动更新
- 提供版本历史和回滚能力
4. Service：解决网络稳定性
Pod是临时的，IP地址会变，如何稳定访问？
- Pod重启后IP会改变
- 扩缩容会导致Pod增减
- 客户端如何发现可用服务？
Service提供了答案：
- 提供稳定的网络端点（IP和DNS名）
- 自动负载均衡到后端Pod
- 服务发现机制
注意： 并非所有Pod都需要Service，但如果需要被网络访问，通常都需要Service。如：
- 前端应用需要Service暴露给用户
- 后端API需要Service供其他服务调用
- 仅做数据处理的批处理Pod可能不需要Service
- 是一个网络抽象层
- 为 Pod 提供稳定的访问端点（IP/DNS）
- 不包含任何容器或运行时代码
- 只是定义了一组网络规则，告诉流量如何路由到 Pod
Service不仅仅是”一组规则”，而是一个完整的Kubernetes资源对象，它包含：
- 虚拟IP(ClusterIP) - 在集群内部稳定不变的IP地址
- 服务发现机制 - 通过DNS或环境变量提供
- 负载均衡功能 - 将流量分发到多个后端Pod
- 端口映射规则 - 定义服务端口与目标Pod端口的映射
- 在实现层面，kube-proxy确实会在每个节点上创建规则(如iptables规则)，但Service本身是一个在控制平面定义和管理的抽象对象。
完整的Kubernetes架构图
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
| +--------------------------------------------------------------------+
| Kubernetes集群 |
+--------------------------------------------------------------------+
|
| 管理
v
+------------------+ +---------------------------+
| 控制平面组件 | | 工作节点 (Node) |
+------------------+ +---------------------------+
| - API Server | | +-----------------------+ |
| - etcd |<--->| | Pod | |
| - Scheduler | | | +-------------------+ | |
| - Controller Mgr | | | | Container Container| | |
+------------------+ | | +-------------------+ | |
| +-----------------------+ |
| |
| +-----------------------+ |
| | Services | |
| | (ClusterIP/NodePort) | |
| +-----------------------+ |
| |
| +-----------------------+ |
| | kubelet | |
| | kube-proxy | |
| | Container Runtime | |
| +-----------------------+ |
+---------------------------+
^
|
+-----------------------------+-----------------------------+
| |
+---------------+ +---------------+ +------------------+ +---------------+
| Deployment | | StatefulSet | | DaemonSet | | Job/CronJob |
+---------------+ +---------------+ +------------------+ +---------------+
| 管理无状态应用 | | 管理有状态应用 | | 每节点运行一个Pod | | 批处理任务 |
+-------+-------+ +---------------+ +------------------+ +---------------+
|
| 管理
v
+---------------+
| ReplicaSet |
+---------------+
| 维护Pod副本数 |
+-------+-------+
|
| 创建
v
+------------------+ 被发现 +------------------+
| Pod |<---------| Service |
+------------------+ 并访问 +------------------+
| 容器组 | | 提供稳定网络终点 |
+------------------+ +------------------+
^ ^
| 挂载 | 配置
+------------------+ +------------------+
| Volume | | ConfigMap/Secret |
+------------------+ +------------------+
| 持久化存储 | | 配置和敏感信息 |
+------------------+ +------------------+
+-------------------------------------------------------------------+
| Kubernetes 集群 |
+-------------------------------------------------------------------+
|
|
v
+------------------------+ +------------------------+
| 控制平面 (Master) | | 工作节点 (Node) |
+------------------------+ +------------------------+
| - API Server | | +--------------------+ |
| - etcd | | | kubelet | |
| - Controller Manager | | | kube-proxy | |
| - Scheduler | | | Container Runtime | |
+------------------------+ | +--------------------+ |
| |
| +--------------------+ |
| | Pod | |
| | +----------------+ | |
| | | Container(s) | | |
| | +----------------+ | |
| +--------------------+ |
| ... |
+------------------------+
+---------------------+ 管理 +---------------------+ 管理 +---------------------+
| Deployment |---------->| ReplicaSet |---------->| Pod |
+---------------------+ +---------------------+ +---------------------+
^
+---------------------+ 管理 +---------------------+ |
| StatefulSet |---------->| Pod | | 选择
+---------------------+ +---------------------+ |
|
+---------------------+ 管理 +---------------------+ +---------------------+
| DaemonSet |---------->| 每个节点上的Pod | | Service |
+---------------------+ +---------------------+ +---------------------+
集群级虚拟IP和负载均衡
+---------------------+ 管理 +---------------------+
| Job/CronJob |---------->| Pod |
+---------------------+ +---------------------+
+-------------------+
| Pod |
+-------------------+
/\
/ \
/ \
挂载卷 / \ 使用配置
/ \
/ \
+--------------+ +--------------+
| Volume | | ConfigMap |
+--------------+ +--------------+
| Secret | | 纯文本配置 |
+--------------+ +--------------+
+----------------------------------+
外部访问 -----------> | Service | 集群级资源
| (ClusterIP/NodePort/LoadBalancer)|
+----------------------------------+
|
| 根据标签选择Pod
| selector: app=myapp
v
+----------------------------------+
| Pod | Pod | Pod | 带有匹配标签的Pod
| app=myapp | app=myapp| app=myapp|
+----------------------------------+
|
这个架构是如何协同工作的：
- 应用打包为容器
- 容器组织为Pod
- ReplicaSet确保Pod高可用
- Deployment管理应用更新
- Service提供稳定访问点
- Deployment ——管理——> ReplicaSet ——管理——> Pod <——选择—— Service
- 各种控制器满足不同应用场景
- 整个系统通过控制平面协调
从单个容器到完整的云原生应用管理平台，Kubernetes的架构正是为了应对分布式系统的各种挑战而逐步设计和演进的。
