第2章：Kubernetes核心概念大白话
五分钟看懂K8s架构，如果把数据中心比作一台巨大的计算机，那么Kubernetes就是这台计算机的操作系统。它让管理成千上万个应用变得像在手机上管理App一样简单。
1. Kubernetes是什么？一句话说清楚
1.1 比喻：数据中心的"操作系统"
想象一下你的电脑：
- Windows/macOS：管理单个电脑的硬件和软件
- Kubernetes：管理整个数据中心的"硬件"和"软件"
| 你的电脑 | Kubernetes集群 |
|---|---|
| 进程管理 | Pod管理 |
| 文件系统 | 持久化存储 |
| 网络配置 | 服务发现和负载均衡 |
| 任务调度 | 工作负载调度 |
| 设备驱动 | 容器运行时 |
1.2 功能：自动化部署、扩展和管理容器化应用
传统运维 vs Kubernetes运维：
# 传统运维的一天
早上9点：手动部署新版本到10台服务器
中午12点：处理服务器宕机，手动重启
下午3点：流量激增，紧急申请新服务器
晚上8点：配置负载均衡，手动调整权重
# Kubernetes运维的一天
早上9点：提交一个YAML文件
然后：喝咖啡，系统自动完成所有工作
Kubernetes的三大核心能力：
- 服务不中断：自动故障恢复，让你的应用"打不死"
- 弹性伸缩：流量来了自动扩容，流量走了自动缩容
- 一次编写，到处运行：无论在哪都能一致部署
2. 核心组件角色扮演：一个完整的"公司"架构
2.1 Master节点：集群的"大脑"和"管理层"
想象Master节点就像公司的总部管理层：
各个"部门"的职责：
(1) API Server：公司的"前台接待"
- 职责：所有请求的统一入口
- 工作方式：
kubectl命令 → API Server → 执行操作 - 特点：唯一可以与etcd通信的组件
# 你执行的每个命令都经过API Server
kubectl get pods # → API Server → 返回结果
kubectl create deployment # → API Server → 创建资源
(2) etcd：公司的"档案室"
- 职责：存储集群的所有状态数据
- 存储内容：节点信息、Pod状态、配置信息等
- 特点：高可用、强一致性，就像不会丢文件的档案室
# etcd中存储的数据示例
集群状态: {
"节点列表": ["worker1", "worker2", "worker3"],
"Pod分布": {
"web-pod-1": "运行在worker1上",
"web-pod-2": "运行在worker2上"
},
"服务配置": {
"前端服务": "监听80端口"
}
}
(3) Controller Manager：公司的"运营总监"
- 职责：确保实际状态与期望状态一致
- 监控内容：节点状态、Pod副本数、服务端点等
# Controller Manager的工作示例
期望状态: 需要运行3个Web应用副本
实际状态: 只有2个副本在运行
Controller Manager: 立即创建第3个副本！
(4) Scheduler：公司的"人力资源部"
- 职责：为Pod分配合适的Worker节点
- 考虑因素：资源需求、策略约束、数据 locality等
# Scheduler的决策过程
def 调度Pod(pod, 可用节点列表):
for 节点 in 可用节点列表:
if 节点.剩余资源 >= pod.所需资源:
if 符合调度策略(节点, pod):
return 节点 # 选择这个节点
return None # 没有合适节点
2.2 Worker节点：干活的"工人"和"生产线"
Worker节点就像公司的生产车间，负责实际运行应用：
(1) Kubelet：车间"主管"
-
职责：与Master节点通信，管理本节点的Pod
-
工作内容：
- 接收Pod创建指令
- 监控容器状态
- 向Master报告节点健康状态
# Kubelet的日常工作
1. 监听API Server: "需要在你这运行一个Pod"
2. 指挥Container Runtime: "启动这个容器"
3. 定期汇报: "老板，我这边一切正常，Pod都在运行"
(2) Container Runtime：生产线"工人"
- 职责：实际运行容器的软件
- 常见选择：Docker、containerd、CRI-O
- 工作内容：拉取镜像、创建容器、管理容器生命周期
# Container Runtime的工作流程
Kubelet: "需要运行nginx容器"
Container Runtime:
1. 检查本地是否有nginx镜像
2. 如果没有，从仓库拉取
3. 创建容器并启动
4. 监控容器运行状态
(3) Kube Proxy：物流"调度员"
-
职责：管理网络规则，实现服务发现和负载均衡
-
工作内容：
- 维护网络规则
- 实现Service的负载均衡
- 处理Pod之间的通信
# Kube Proxy的工作示例
用户访问: http://前端服务
Kube Proxy:
- 查看服务端点列表
- 将请求转发到某个具体的Pod
- 如果Pod故障，自动切换到其他Pod
2.3 Pod：最小的"工作单元"和"办公室隔间"
(1) 什么是Pod？为什么需要Pod？
Pod的简单理解：
一个Pod就像办公室里的一个工作隔间，里面可以坐1个或多个人（容器），他们共享电话、文件柜等资源。
# 一个典型的Pod定义
apiVersion: v1
kind: Pod
metadata:
name: web-app-pod
spec:
containers:
- name: web-server
image: nginx:1.19
ports:
- containerPort: 80
- name: log-collector
image: fluentd:latest
# 这两个容器共享网络和存储空间
为什么不是直接管理容器？
- 亲密关系：有些容器需要紧密协作，共享资源
- 原子性：Pod内的容器一起调度、一起运行
- 简化网络：Pod内的容器通过localhost直接通信
(2) Pod的典型场景
场景1：Web应用 + 日志收集器
containers:
- name: web-app # 主应用容器
image: my-app:1.0
- name: log-sidecar # 日志收集sidecar
image: fluentd:latest
# 它们共享日志文件目录
场景2：文件处理器 + 文件同步器
containers:
- name: file-processor # 处理文件
image: processor:1.0
- name: file-syncer # 同步文件到云端
image: syncer:1.0
# 它们共享同一个存储卷
3. Kubernetes架构图解：一张图看懂整体架构
3.1 完整架构图（文字描述）
┌─────────────────────────────────────────────────────────────────┐
│ Kubernetes Cluster │
│ │
│ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ Master Node │ │ Worker Node 1 │ │
│ │ │ │ │ │
│ │ ┌────────────┐ │ ┌───────────┐ │ ┌───────────────┐ │ │
│ │ │ API Server │◄┼───┤ etcd │ │ │ Kubelet │ │ │
│ │ └────────────┘ │ └───────────┘ │ └───────────────┘ │ │
│ │ │ │ │ │ │ │ │
│ │ ┌────────────┐ │ ┌────────────┐ │ ┌───────────────┐ │ │
│ │ │ Scheduler │ │ │ Controller │ │ │ Container │ │ │
│ │ └────────────┘ │ │ Manager │ │ │ Runtime │ │ │
│ │ │ └────────────┘ │ └───────────────┘ │ │
│ └─────────────────┘ │ │ │ │
│ │ │ ┌───────────────┐ │ │
│ └──────────────────┼─►│ Kube Proxy │ │ │
│ │ └───────────────┘ │ │
│ │ │ │
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
│ │ Worker Node 2 │ │
│ │ │ │
│ │ ┌───────────────┐ │ │
│ │ │ Kubelet │ │ │
│ │ └───────────────┘ │ │
│ │ │ │ │
│ │ ┌───────────────┐ │ │
│ │ │ Container │ │ │
│ │ │ Runtime │ │ │
│ │ └───────────────┘ │ │
│ ┌──────────────────┼─►│ Kube Proxy │ │ │
│ │ │ └───────────────┘ │ │
│ │ │ │ │
│ │ └─────────────────────┘ │
│ │ │
│ │ ┌─────────────────────┐ │
│ │ │ Worker Node N │ │
│ │ │ │ │
│ │ │ ... │ │
│ │ │ │ │
│ └──────────────────► │ │
│ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3.2 数据流向：一次完整的请求处理
让我们跟踪一个kubectl create命令的完整生命周期：
# 1. 用户执行命令
kubectl create -f my-app.yaml
# 2. 请求旅程开始
步骤详解：
-
命令提交 → API Server
你的电脑 → kubectl → API Server (认证、授权、验证) -
状态存储 → etcd
API Server → 将期望状态写入etcd 存储内容: "需要运行3个my-app副本" -
状态监控 → Controller Manager
Controller Manager监控etcd变化: - 发现期望状态: 3个副本 - 检查实际状态: 0个副本 - 创建Pod定义: 3个Pod -
调度决策 → Scheduler
Scheduler为每个Pod选择节点: - 过滤: 哪些节点满足资源要求 - 评分: 哪个节点最优 - 绑定: 将Pod绑定到节点 -
任务执行 → Kubelet
目标节点的Kubelet: - 监听到有新Pod需要运行 - 指挥Container Runtime启动容器 - 监控容器状态并定期报告 -
网络配置 → Kube Proxy
所有节点的Kube Proxy: - 更新网络规则 - 配置负载均衡 - 确保服务可访问
3.3 现实世界的类比
为了更好理解，我们把Kubernetes组件映射到一个快递公司：
| Kubernetes组件 | 快递公司类比 | 职责说明 |
|---|---|---|
| API Server | 客服中心 | 接收所有客户请求，协调内部工作 |
| etcd | 订单数据库 | 存储所有订单状态和配送信息 |
| Scheduler | 路线规划师 | 决定哪个快递员配送哪个包裹 |
| Controller Manager | 运营监控 | 确保包裹按时送达，处理异常情况 |
| Kubelet | 快递站点经理 | 管理本站点的快递员和包裹 |
| Container Runtime | 快递员 | 实际执行配送任务 |
| Kube Proxy | 导航系统 | 确保包裹能找到正确的收货地址 |
| Pod | 配送车辆 | 可以装载多个包裹（容器），一起配送 |
4. 总结：为什么这个架构很重要？
4.1 架构优势
- 高可用性：Master组件可以多副本部署，避免单点故障
- 可扩展性：可以轻松添加更多Worker节点
- 松耦合：组件各司其职，通过API通信
- 自我修复：自动检测和恢复故障
4.2 设计哲学
Kubernetes的架构体现了几个重要的设计原则：
- 声明式API：告诉系统"想要什么"，而不是"怎么做"
- 控制器模式：不断驱动当前状态向期望状态收敛
- 面向API设计：所有功能都通过API暴露，易于扩展
4.3 下一步学习什么？
理解了基础架构后，接下来我们要学习：
- Pod的详细用法：如何定义和管理最基本的部署单元
- 控制器模式：如何使用Deployment、StatefulSet等管理Pod
- 服务发现：如何让Pod之间能够相互通信
- 存储管理：如何处理有状态应用的数据持久化
记住：Kubernetes的架构虽然复杂，但它的设计思想很直观 - 就像管理一个高效的公司一样，每个组件都有明确的职责，协同工作来实现自动化运维。
动手练习：在你的环境中安装Minikube，然后运行kubectl get nodes和kubectl get pods -A，观察输出结果，尝试理解每个组件的作用。
