在抽离所有技术细节之后,Kubernetes 要解决的本质问题只有一个:
如何在不确定的基础设施之上,可靠地运行确定的应用意图?
更抽象地说:
Kubernetes 的设计基于四个根本思想:
| 思想 | 含义 |
|---|---|
| 声明式 | 描述“要什么”,而不是“怎么做” |
| 控制器模型 | 通过不断对比期望状态与实际状态来修正系统 |
| 资源抽象 | 用统一的 API 描述一切 |
| 基础设施即资源池 | 屏蔽底层节点差异 |
从认知高度,可以把 Kubernetes 抽象为:
用户意图(YAML)
↓
API Server(期望状态存储)
↓
控制器模型(Reconciliation Loop)
↓
调度 + 执行
↓
最终运行态
Kubernetes 可以被简化为三层模型:
+-----------------------------+
| API & 资源层 |
| Pod / Service / Deployment |
+-----------------------------+
| 控制层 |
| Controller + Scheduler |
+-----------------------------+
| 执行层 |
| kubelet + CRI + CNI |
+-----------------------------+
一切 Kubernetes 组件都遵循同一范式:
for {
actual := getActualState()
desired := getDesiredState()
if actual != desired {
makeThemEqual()
}
}
这就是 Kubernetes 最核心的第一性原理:
期望状态驱动的自动化收敛系统
控制平面的本质是:
一个分布式意图处理系统
| 组件 | 本质职责 |
|---|---|
| API Server | 意图网关 |
| etcd | 状态之源 |
| Scheduler | 资源决策 |
| Controller Manager | 状态收敛 |
所有组件只与 API Server 通信
构成“单一真相源”
提供:
本质:
API Server = Kubernetes 的“大脑皮层”
本质公式:
Kubernetes 的可靠性 ≈ etcd 的可靠性
调度本质:
在资源池中寻找最合适的节点
逻辑模型:
未调度 Pod
↓
过滤可用节点
↓
打分
↓
绑定节点
负责让系统:
从“实际状态” → “期望状态”
本质:
“节点上的执行代理”
把 Pod 描述变为真实容器
负责:
本质:
Service 网络规则控制器
真正转发流量的是:
kube-proxy 的定位:
不是代理,而是“规则编程器”
| 接口 | 抽象目的 |
|---|---|
| CRI | 运行时解耦 |
| CNI | 网络解耦 |
| CSI | 存储解耦 |
体现 Kubernetes 的核心设计思想:
一切皆可插拔
本质定义:
Pod = 一个逻辑主机
共享:
容器与 Pod 的关系:
| 比喻层 | 对应 |
|---|---|
| Pod | 机器 |
| Container | 进程 |
Service 的本质:
为动态 Pod 集合提供稳定访问点
三大功能:
本质:
版本化的副本控制器
Deployment
↓
ReplicaSet
↓
Pod
解决两个问题:
| 维度 | 含义 |
|---|---|
| 拓扑状态 | 编号顺序 |
| 存储状态 | 独立 PVC |
| 对象 | 场景本质 |
|---|---|
| DaemonSet | 节点守护进程 |
| Job | 一次性任务 |
| CronJob | 定时任务 |
Kubernetes 网络的第一性原理:
任何 Pod 可以无 NAT 直连任何 Pod
Kubernetes 存储的核心理念:
存储与计算解耦
抽象层级:
Pod
↓
PVC(声明)
↓
PV(资源)
↓
StorageClass(策略)
Kubernetes 安全的三个维度:
| 维度 | 机制 |
|---|---|
| 身份 | ServiceAccount |
| 权限 | RBAC |
| 隔离 | NetworkPolicy |
现代运维三件套:
| 能力 | 实现 |
|---|---|
| Metrics | Prometheus |
| Logging | EFK/ELK |
| Tracing | OpenTelemetry |
| 模式 | 场景 |
|---|---|
| 滚动更新 | 常规发布 |
| 蓝绿发布 | 大版本 |
| 金丝雀 | 灰度 |
Kubernetes 不是什么:
它是:
分布式应用的运行时平台