云原生技术原理分层详解
核心结论：云原生的本质是"容器化封装 + 自动化编排 + 弹性伸缩 + 声明式管理"。理解云原生，要从底层原理逐层向上，打通「运行时 → 编排 → 网络 → 存储 → 治理 → 可观测」六层技术栈。
目录
-
第零层：云原生架构全景图
-
第一层：容器运行时原理
-
第二层：Kubernetes 核心原理
-
第三层：网络原理
-
第四层：存储原理
-
第五层：服务治理原理
-
第六层：可观测性原理
-
附录：快速上手实验清单
第零层：云原生架构全景图
技术栈分层架构
┌─────────────────────────────────────────────────────────────┐
│ 应用层 │
│ 微服务 / Serverless / AI应用 │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ 治理层 │
│ 服务网格(Istio) / API网关 / 配置中心 │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ 编排层 │
│ Kubernetes 控制平面 │
│ (API Server / Scheduler / Controller / etcd) │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ 运行时层 │
│ 容器运行时(containerd) + CRI + OCI 运行时 │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ 基础设施层 │
│ 计算 / 网络 / 存储 / 云服务 / 物理机 │
└─────────────────────────────────────────────────────────────┘CNCF 云原生定义
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、不可变基础设施、声明式API。
四大支柱：
| 支柱 | 定义 | 核心技术 |
|---|---|---|
| 容器 | 轻量级虚拟化技术 | Docker、containerd、CRI-O |
| 服务网格 | 服务间通信基础设施 | Istio、Linkerd、Envoy |
| 不可变基础设施 | 基础设施即代码，不手动修改 | Terraform、Packer、GitOps |
| 声明式API | 描述期望状态，而非操作步骤 | Kubernetes API、CRD |
第一层：容器运行时原理
1.1 容器的本质
核心概念：容器不是虚拟机，而是"被隔离的进程"。
┌─────────────────────────────────────────────────────────────┐
│ 虚拟机 vs 容器 │
├─────────────────────────────────────────────────────────────┤
│ 虚拟机架构： │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ App A │ │ App B │ │ App C │ │
│ ├─────────┤ ├─────────┤ ├─────────┤ │
│ │Guest OS │ │Guest OS │ │Guest OS │ ← 每个VM需要完整OS │
│ ├─────────┴──┴─────────┴──┴─────────┤ │
│ │ Hypervisor │ │
│ ├───────────────────────────────────┤ │
│ │ Host OS │ │
│ └───────────────────────────────────┘ │
│ 启动：分钟级 | 资源开销：GB级 | 隔离：强 │
│ │
│ 容器架构： │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ App A │ │ App B │ │ App C │ │
│ ├─────────┤ ├─────────┤ ├─────────┤ │
│ │ Libs │ │ Libs │ │ Libs │ ← 共享宿主内核 │
│ └─────────┴──┴─────────┴──┴─────────┘ │
│ ├─────────────────────────────────────┤ │
│ │ Container Runtime │ │
│ ├─────────────────────────────────────┤ │
│ │ Host OS / Kernel │ │
│ └─────────────────────────────────────┘ │
│ 启动：秒级 | 资源开销：MB级 | 隔离：进程级 │
└─────────────────────────────────────────────────────────────┘1.2 容器底层技术：Namespaces + Cgroups
Namespaces：视图隔离
作用：让进程"看"不到其他进程和系统资源，实现"眼罩"隔离。
六种 Namespace：
| Namespace | 隔离内容 | 系统调用参数 | 示例 |
|---|---|---|---|
| PID | 进程ID | CLONE_NEWPID | 容器内进程从PID=1开始 |
| NET | 网络栈 | CLONE_NEWNET | 独立的网卡、路由表、iptables |
| MNT | 挂载点 | CLONE_NEWNS | 独立的文件系统视图 |
| UTS | 主机名 | CLONE_NEWUTS | 独立的hostname |
| IPC | 进程间通信 | CLONE_NEWIPC | 独立的信号量、消息队列 |
| USER | 用户ID | CLONE_NEWUSER | root在容器外是普通用户 |
Namespace 查看方式：
# 查看进程的 Namespace
ls -la /proc/<pid>/ns/
# 输出示例：
lrwxrwxrwx 1 root root 0 Apr 17 10:00 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Apr 17 10:00 ipc -> 'ipc:[4026532234]'
lrwxrwxrwx 1 root root 0 Apr 17 10:00 mnt -> 'mnt:[4026532232]'
lrwxrwxrwx 1 root root 0 Apr 17 10:00 net -> 'net:[4026532237]'
lrwxrwxrwx 1 root root 0 Apr 17 10:00 pid -> 'pid:[4026532235]'
lrwxrwxrwx 1 root root 0 Apr 17 10:00 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Apr 17 10:00 uts -> 'uts:[4026532233]'
# 数字相同的进程在同一个 Namespace 中Cgroups：资源限制
作用：限制进程能使用的CPU、内存、IO等资源，实现"手铐"限制。
Cgroups 子系统：
| 子系统 | 限制内容 | 关键文件 |
|---|---|---|
| cpu | CPU时间片 | cpu.cfs_quota_us / cpu.cfs_period_us |
| cpuacct | CPU使用统计 | cpuacct.usage |
| cpuset | CPU核心绑定 | cpuset.cpus |
| memory | 内存使用 | memory.limit_in_bytes |
| blkio | 块设备IO | blkio.throttle.read_bps_device |
| devices | 设备访问 | devices.allow / devices.deny |
| freezer | 进程冻结 | freezer.state |
Cgroups 配置示例：
# Docker 运行时传递的参数
docker run -d \
--name myapp \
--memory=512m \ # 内存限制
--memory-swap=1g \ # 内存+交换分区限制
--cpus=2 \ # CPU核数限制
--cpu-shares=512 \ # CPU权重（相对值）
--device-read-bps=/dev/sda:10MB \ # 读IO限制
nginx
# 底层写入 cgroup 文件
/sys/fs/cgroup/memory/docker/<container_id>/memory.limit_in_bytes = 536870912
/sys/fs/cgroup/cpu/docker/<container_id>/cpu.cfs_quota_us = 200000
/sys/fs/cgroup/cpu/docker/<container_id>/cpu.cfs_period_us = 1000001.3 镜像原理：分层存储
核心概念：镜像是"只读层"的叠加，容器是镜像 + 可写层。
┌─────────────────────────────────────────────────────────────┐
│ 镜像分层结构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 容器运行时视图： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Container Layer (Read-Write) │ │
│ │ 所有修改都写到这里 │ │
│ │ • 新建文件 │ │
│ │ • 修改文件（Copy-on-Write） │ │
│ │ • 删除文件（Whiteout 标记） │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Layer N: Application Code (Read-Only) │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Layer N-1: Dependencies (Read-Only) │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Layer 2: Runtime (Read-Only) │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Layer 1: Base OS (Read-Only) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 存储驱动：Overlay2（主流） │
│ │
│ 目录结构： │
│ /var/lib/docker/overlay2/ │
│ ├── <lower-id>/diff/ # 只读层内容 │
│ ├── <upper-id>/diff/ # 可写层内容 │
│ ├── <work-id>/work/ # 工作目录 │
│ └── <merged>/ # 合并视图（容器看到的内容） │
│ │
└─────────────────────────────────────────────────────────────┘Copy-on-Write（写时复制）机制：
读取文件：
从各层直接读取，无需复制
修改文件：
1. 从只读层复制文件到可写层
2. 在可写层修改文件
3. 后续读取使用可写层的版本
删除文件：
在可写层创建 Whiteout 文件（.wh.<filename>）
隐藏只读层的文件，不实际删除多阶段构建优化镜像：
# 构建阶段
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main .
# 运行阶段（只包含编译产物）
FROM alpine:3.19
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/main .
EXPOSE8080
CMD ["./main"]
# 结果：镜像从 1GB+ 减小到 20MB1.4 容器运行时接口（CRI）
CRI 架构：
┌─────────────────────────────────────────────────────────────┐
│ Kubernetes │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Kubelet │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ CRI (gRPC API) │ │ │
│ │ │ RuntimeService / ImageService │ │ │
│ │ └───────────────────────┬───────────────────────┘ │ │
│ └──────────────────────────┼──────────────────────────┘ │
└─────────────────────────────┼─────────────────────────────┘
│ gRPC 调用
▼
┌─────────────────────────────────────────────────────────────┐
│ 容器运行时（CRI 实现） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ containerd / CRI-O / Docker Engine │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ OCI Runtime Interface │ │ │
│ │ └───────────────────────┬───────────────────────┘ │ │
│ └──────────────────────────┼──────────────────────────┘ │
└─────────────────────────────┼─────────────────────────────┘
│ 调用 OCI 运行时
▼
┌─────────────────────────────────────────────────────────────┐
│ OCI 运行时（底层） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ runc / crun / runsc (gVisor) / kata-containers │ │
│ │ │ │
│ │ runc: 标准容器运行时，直接使用 namespace/cgroups │ │
│ │ crun: C语言实现，启动更快 │ │
│ │ runsc: 安全沙箱，每个容器一个独立内核 │ │
│ │ kata: 轻量级虚拟机，强隔离 │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘第二层：Kubernetes 核心原理
2.1 Kubernetes 架构全景
┌─────────────────────────────────────────────────────────────┐
│ Kubernetes 集群架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Control Plane（控制平面） │ │
│ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ API Server │ │ Scheduler │ │Controller │ │ │
│ │ │ │ │ │ │Manager │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ 统一入口 │ │ Pod调度 │ │ 状态调和 │ │ │
│ │ │ 认证授权 │ │ 节点选择 │ │ 控制循环 │ │ │
│ │ └─────┬──────┘ └────────────┘ └────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ etcd（分布式存储） │ │ │
│ │ │ │ │ │
│ │ │ • 存储：集群所有状态数据 │ │ │
│ │ │ • 协议：Raft 一致性协议 │ │ │
│ │ │ • 特点：强一致性、高可用 │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │ │
│ │ API 调用 │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Data Plane（数据平面） │ │
│ │ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ Node 1 │ │ Node 2 │ │ │
│ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │
│ │ │ │ Kubelet │ │ │ │ Kubelet │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ 节点代理 │ │ │ │ 节点代理 │ │ │ │
│ │ │ │ Pod管理 │ │ │ │ Pod管理 │ │ │ │
│ │ │ └───────────┘ │ │ └───────────┘ │ │ │
│ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │
│ │ │ │Kube-Proxy │ │ │ │Kube-Proxy │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ Service规则│ │ │ │ Service规则│ │ │ │
│ │ │ └───────────┘ │ │ └───────────┘ │ │ │
│ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │
│ │ │ │Container │ │ │ │Container │ │ │ │
│ │ │ │Runtime │ │ │ │Runtime │ │ │ │
│ │ │ └───────────┘ │ │ └───────────┘ │ │ │
│ │ │ Pods: 🐳🐳 │ │ Pods: 🐳🐳 │ │ │
│ │ └─────────────────┘ └─────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘2.2 控制平面组件详解
API Server
职责：集群统一入口，RESTful API，认证授权，准入控制。
┌─────────────────────────────────────────────────────────────┐
│ API Server 请求处理流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Client │ kubectl / 应用 / 其他组件 │
│ │ Request │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 认证（Authentication） │ │
│ │ • 客户端证书 │ │
│ │ • Bearer Token │ │
│ │ • OpenID Connect │ │
│ │ • Webhook │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 2. 授权（Authorization） │ │
│ │ • RBAC（Role-Based Access Control） │ │
│ │ • ABAC（Attribute-Based） │ │
│ │ • Node Authorizer │ │
│ │ • Webhook │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 3. 准入控制（Admission Control） │ │
│ │ • ValidatingWebhook（验证） │ │
│ │ • MutatingWebhook（修改） │ │
│ │ • 内置插件（LimitRanger、ResourceQuota等） │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 4. 验证 & 默认值填充 │ │
│ │ • Schema 验证 │ │
│ │ • 默认值设置 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 5. 写入 etcd │ │
│ │ • 乐观并发控制（ResourceVersion） │ │
│ │ • 事务性写入 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘etcd：分布式键值存储
职责：存储集群所有状态数据，是 Kubernetes 的"数据库"。
etcd 数据结构：
# 键值存储结构
/registry/
├── pods/
│ └── default/
│ ├── nginx-xxx
│ └── redis-xxx
├── services/
│ └── default/
│ └── kubernetes
├── deployments/
│ └── default/
│ └── nginx
├── configmaps/
├── secrets/
├── nodes/
├── ...Raft 一致性协议：
┌─────────────────────────────────────────────────────────────┐
│ Raft 协议工作原理 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 集群节点（通常 3 或 5 个）： │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Leader │────▶│Follower │ │Follower │ │
│ │ │ │ │ │ │ │
│ │ 处理写 │ │ 响应 │ │ 响应 │ │
│ │ 请求 │ │ Leader │ │ Leader │ │
│ └────┬────┘ └─────────┘ └─────────┘ │
│ │ │
│ │ 心跳 + 日志复制 │
│ └──────────────────────────────────▶ │
│ │
│ 写入流程： │
│ 1. 客户端发送写请求到 Leader │
│ 2. Leader 将操作追加到日志 │
│ 3. Leader 将日志复制到大多数 Follower │
│ 4. 收到大多数确认后，Leader 提交日志 │
│ 5. 响应客户端成功 │
│ │
│ 选举流程： │
│ 1. Follower 超时未收到心跳，转为 Candidate │
│ 2. Candidate 请求投票 │
│ 3. 获得大多数投票后成为 Leader │
│ │
└─────────────────────────────────────────────────────────────┘Scheduler：Pod 调度器
职责：将 Pod 绑定到合适的节点。
调度流程：
┌─────────────────────────────────────────────────────────────┐
│ Pod 调度流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 预调度（Predicates / Filtering） │ │
│ │ │ │
│ │ 过滤掉不满足条件的节点： │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ PodFitsResources │ 资源是否充足 │ │ │
│ │ │ PodFitsHostPorts │ 端口是否冲突 │ │ │
│ │ │ PodMatchNodeSelector │ 节点选择器匹配 │ │ │
│ │ │ PodToleratesNodeTaints │ 污点容忍匹配 │ │ │
│ │ │ CheckNodeCondition │ 节点状态正常 │ │ │
│ │ │ CheckNodeUnschedulable │ 节点可调度 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 2. 优先级排序（Priorities / Scoring） │ │
│ │ │ │
│ │ 对可行节点打分（0-100分）： │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ LeastRequestedPriority │ 资源剩余最多 │ │ │
│ │ │ BalancedResourceAllocation │ CPU/内存均衡 │ │ │
│ │ │ NodeAffinityPriority │ 节点亲和性 │ │ │
│ │ │ InterPodAffinityPriority │ Pod亲和性 │ │ │
│ │ │ TaintTolerationPriority │ 污点容忍 │ │ │
│ │ │ ImageLocalityPriority │ 镜像已存在 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 最终得分 = Σ(权重 × 单项得分) │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 3. 绑定（Binding） │ │
│ │ │ │
│ │ • 选择得分最高的节点 │ │
│ │ • 创建 Binding 对象，写入 etcd │ │
│ │ • Kubelet 监听到绑定事件，启动 Pod │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Controller Manager：控制器管理器
职责：运行各种控制器，维持集群期望状态。
核心概念：声明式 API + 控制循环：
┌─────────────────────────────────────────────────────────────┐
│ 控制器模式（Reconcile Loop） │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ 用户定义 │ │
│ │ 期望状态 │ │
│ │ (Desired) │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 控制循环（无限循环） │ │
│ │ │ │
│ │ while true: │ │
│ │ 1. 获取期望状态（从 etcd） │ │
│ │ desired = GetDesiredState() │ │
│ │ │ │
│ │ 2. 获取实际状态（从集群） │ │
│ │ actual = GetActualState() │ │
│ │ │ │
│ │ 3. 比较差异 │ │
│ │ diff = Compare(desired, actual) │ │
│ │ │ │
│ │ 4. 执行调和动作 │ │
│ │ if actual < desired: │ │
│ │ CreateResources(diff.needed) │ │
│ │ elif actual > desired: │ │
│ │ DeleteResources(diff.extra) │ │
│ │ else: │ │
│ │ UpdateResources(diff.changed) │ │
│ │ │ │
│ │ 5. 更新状态 │ │
│ │ UpdateStatus() │ │
│ │ │ │
│ │ 6. 等待下次循环 │ │
│ │ sleep(100ms) │ │
│ │ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 实际状态 │ │
│ │ (Actual) │ │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘常用控制器：
| 控制器 | 职责 | 监听对象 |
|---|---|---|
| Deployment Controller | 管理 ReplicaSet，滚动更新 | Deployment |
| ReplicaSet Controller | 维护 Pod 副本数 | ReplicaSet |
| StatefulSet Controller | 有状态应用，有序部署 | StatefulSet |
| DaemonSet Controller | 每个节点一个 Pod | DaemonSet |
| Job Controller | 一次性任务 | Job |
| CronJob Controller | 定时任务 | CronJob |
| Node Controller | 节点健康检查 | Node |
| Service Controller | 服务负载均衡 | Service |
| Endpoint Controller | 维护 Endpoints | Service |
2.3 Pod 原理
核心概念：Pod 是 Kubernetes 最小调度单位，是一组共享网络和存储的容器集合。
┌─────────────────────────────────────────────────────────────┐
│ Pod 内部结构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Pod │ │
│ │ │ │
│ │ 共享资源： │ │
│ │ • 网络命名空间（同一 IP、端口空间） │ │
│ │ • IPC 命名空间（可通过信号量通信） │ │
│ │ • 存储卷（共享 Volume） │ │
│ │ • 主机名（同一 UTS namespace） │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Pause 容器（根容器） │ │ │
│ │ │ │ │ │
│ │ │ 作用： │ │ │
│ │ │ 1. 创建并持有网络命名空间 │ │ │
│ │ │ 2. 启动命令：/pause（无限睡眠） │ │ │
│ │ │ 3. 其他容器通过 Join 进入该命名空间 │ │ │
│ │ │ │ │ │
│ │ │ 为什么需要？ │ │ │
│ │ │ • 主容器崩溃重启时，网络命名空间不丢失 │ │ │
│ │ │ • Pod IP 不变 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 主容器 │ │ 边车容器 │ │ │
│ │ │ (Main) │ │ (Sidecar) │ │ │
│ │ │ │ │ │ │ │
│ │ │ nginx │ │ log-agent │ │ │
│ │ │ 业务进程 │ │ 采集日志 │ │ │
│ │ │ │ │ │ │ │
│ │ └──────┬───────┘ └──────┬───────┘ │ │
│ │ │ │ │ │
│ │ └────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌────────┴────────┐ │ │
│ │ │ 共享 Volume │ │ │
│ │ │ (emptyDir) │ │ │
│ │ │ │ │ │
│ │ │ 主容器写日志 → │ │ │
│ │ │ Sidecar 读取 │ │ │
│ │ └─────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Pod 生命周期：
┌─────────────────────────────────────────────────────────────┐
│ Pod 生命周期状态 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Pending → Running → Succeeded / Failed │
│ ↘ CrashLoopBackOff │
│ │
│ 状态说明： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Pending │ Pod 已创建，等待调度 │ │
│ │ Running │ Pod 已调度，至少一个容器运行中 │ │
│ │ Succeeded │ 所有容器成功退出（不会重启） │ │
│ │ Failed │ 所有容器退出，至少一个失败 │ │
│ │ Unknown │ 无法获取 Pod 状态 │ │
│ │ CrashLoopBackOff│ 容器反复崩溃重启 │ │
│ │ ImagePullBackOff│ 镜像拉取失败 │ │
│ │ Evicted │ 资源不足被驱逐 │ │
│ │ Terminating │ 正在终止 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 容器状态： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Waiting │ 等待启动（镜像拉取、资源分配） │ │
│ │ Running │ 运行中 │ │
│ │ Terminated │ 已终止（成功或失败） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 重启策略（restartPolicy）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Always │ 总是重启（默认） │ │
│ │ OnFailure │ 失败时重启 │ │
│ │ Never │ 从不重启 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘2.4 Service 原理
核心概念：Service 通过 Label Selector 绑定 Pod，提供稳定访问入口。
┌─────────────────────────────────────────────────────────────┐
│ Service 工作原理 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Service (ClusterIP 类型) │ │
│ │ │ │
│ │ ClusterIP: 10.96.0.1 (虚拟 IP) │ │
│ │ Port: 80 │ │
│ │ TargetPort: 8080 │ │
│ │ Selector: app=nginx │ │
│ │ │ │
│ │ 作用： │ │
│ │ • 提供稳定的访问入口（Pod IP 会变，Service IP 不变）│ │
│ │ • 负载均衡到后端 Pod │ │
│ │ • 服务发现（DNS 解析） │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ │ 自动维护 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Endpoints / EndpointSlice │ │
│ │ │ │
│ │ 自动维护的 Pod IP 列表： │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ 10.244.1.2:8080 │ │ │
│ │ │ 10.244.2.3:8080 │ │ │
│ │ │ 10.244.3.4:8080 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 更新机制： │ │
│ │ • Endpoint Controller 监听 Service 和 Pod │ │
│ │ • Pod 创建/删除时，自动更新 Endpoints │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Pod 1 │ │ Pod 2 │ │ Pod 3 │ │
│ │10.244.1.2│ │10.244.2.3│ │10.244.3.4│ │
│ │app=nginx │ │app=nginx │ │app=nginx │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Service 四种类型：
| 类型 | ClusterIP | NodePort | LoadBalancer | ExternalName |
|---|---|---|---|---|
| 访问方式 | 集群内部 | 节点端口 | 云负载均衡器 | DNS CNAME |
| 适用场景 | 内部服务 | 暴露服务 | 云环境 | 外部服务 |
| 示例 | ClusterIP: 10.96.0.1 | NodePort: 30080 | EXTERNAL-IP: 1.2.3.4 | externalName: api.example.com |
Kube-Proxy 三种模式：
┌─────────────────────────────────────────────────────────────┐
│ Kube-Proxy 工作模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. userspace 模式（已淘汰） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Client → kube-proxy(用户态) → Pod │ │
│ │ │ │
│ │ 特点： │ │
│ │ • 所有流量经过 kube-proxy │ │
│ │ • 性能差，用户态/内核态切换开销大 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 2. iptables 模式（默认） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Client → iptables(内核) → Pod │ │
│ │ │ │
│ │ 规则链示例： │ │
│ │ KUBE-SERVICES → KUBE-SVC-XXX → KUBE-SEP-XXX │ │
│ │ │ │
│ │ 特点： │ │
│ │ • 内核态转发，性能好 │ │
│ │ • 规则数随 Service 增长（O(n)） │ │
│ │ • 更新规则需要重建整条链 │ │
│ │ • 随机负载均衡（概率） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 3. IPVS 模式（推荐大规模集群） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Client → IPVS(内核负载均衡) → Pod │ │
│ │ │ │
│ │ 特点： │ │
│ │ • 专为负载均衡设计 │ │
│ │ • 支持多种调度算法（rr/lc/dh/sh/sed/nq） │ │
│ │ • 规则更新是增量操作 │ │
│ │ • 性能最优 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘第三层：网络原理
3.1 Kubernetes 网络模型
四大原则：
- 所有 Pod 不使用 NAT 就能相互通信
- 所有 Node 不使用 NAT 就能与所有 Pod 通信
- Pod 看到的自己 IP 与别人看到的它的 IP 相同
- Service 的 ClusterIP 是虚拟 IP，不可 ping
3.2 CNI（容器网络接口）
CNI 工作流程：
┌─────────────────────────────────────────────────────────────┐
│ CNI 插件工作流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. Kubelet 创建 Pod，调用 CNI 插件 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 2. CNI 插件分配 IP 地址 │ │
│ │ • 从配置的网段分配 │ │
│ │ • 记录 IP 分配状态 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 3. 创建网络设备 │ │
│ │ • veth pair（虚拟网线） │ │
│ │ • 网桥（cni0） │ │
│ │ • 路由规则 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 4. 将网络命名空间连接到网络 │ │
│ │ • 一端放入 Pod 网络命名空间 │ │
│ │ • 一端连接到主机网络 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 5. 返回结果给 Kubelet │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘3.3 跨节点 Pod 通信原理
以 Flannel VXLAN 为例：
┌─────────────────────────────────────────────────────────────┐
│ 跨节点 Pod 通信（VXLAN 隧道） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 节点 A (192.168.1.10) 节点 B (192.168.1.11) │
│ ┌───────────────────────┐ ┌───────────────────────┐ │
│ │ Pod: 10.244.1.2 │ │ Pod: 10.244.2.3 │ │
│ │ │ │ │ ▲ │ │
│ │ ▼ │ │ │ │ │
│ │ ┌─────────┐ │ │ ┌─────────┐ │ │
│ │ │ eth0 │ │ │ │ eth0 │ │ │
│ │ │10.244.1.2│ │ │ │10.244.2.3│ │ │
│ │ └────┬────┘ │ │ └────┬────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │
│ │ │veth pair│ │ │ │veth pair│ │ │
│ │ └────┬────┘ │ │ └────┬────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │
│ │ │ cni0 │ │ │ │ cni0 │ │ │
│ │ │ (网桥) │ │ │ │ (网桥) │ │ │
│ │ └────┬────┘ │ │ └────┬────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │
│ │ │flannel.1│ │ │ │flannel.1│ │ │
│ │ │(VTEP) │◄────────┼───────┼─▶│(VTEP) │ │ │
│ │ └────┬────┘ │ │ └────┬────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │
│ │ │ eth0 │ │ │ │ eth0 │ │ │
│ │ │192.168.1.10│ │ │ │192.168.1.11│ │ │
│ │ └────┬────┘ │ │ └────┬────┘ │ │
│ └────────┼──────────────┘ └────────┼──────────────┘ │
│ │ │ │
│ └─────────── VXLAN 隧道 ────────┘ │
│ │
│ 数据包封装过程： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 原始包：[10.244.1.2 → 10.244.2.3 | 数据] │ │
│ │ │ │
│ │ VXLAN 封装： │ │
│ │ [外层IP: 192.168.1.10 → 192.168.1.11] │ │
│ │ [外层UDP: 8472] │ │
│ │ [VXLAN Header: VNI=1] │ │
│ │ [内层IP: 10.244.1.2 → 10.244.2.3 | 数据] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘3.4 主流 CNI 方案对比
| 方案 | 原理 | 性能 | 网络策略 | 适用场景 |
|---|---|---|---|---|
| Flannel | VXLAN/Host-GW | 中 | 不支持 | 中小集群、简单场景 |
| Calico | BGP 路由 | 高 | 支持 | 大规模、需要网络策略 |
| Cilium | eBPF | 最高 | 支持 | 高性能、可观测性要求高 |
| Weave | VXLAN | 中 | 支持 | 多云混合 |
| Canal | Flannel + Calico | 中 | 支持 | 简单网络 + 网络策略 |
3.5 Ingress 原理
┌─────────────────────────────────────────────────────────────┐
│ Ingress 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 外部流量 │ │
│ │ (HTTP/HTTPS 请求) │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LoadBalancer / NodePort │ │
│ │ (四层负载均衡) │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Ingress Controller │ │
│ │ (Nginx / Traefik / Kong / Istio Gateway) │ │
│ │ │ │
│ │ 功能： │ │
│ │ • 七层路由（基于域名、路径） │ │
│ │ • TLS 终止（证书管理） │ │
│ │ • 负载均衡 │ │
│ │ • 限流、认证 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Service │ │ Service │ │ Service │ │
│ │ API │ │ Web │ │ Admin │ │
│ │api.svc │ │web.svc │ │admin.svc │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Pods Pods Pods │
│ │
└─────────────────────────────────────────────────────────────┘Ingress 资源示例：
apiVersion: networking.k8s.io/v1
kind:Ingress
metadata:
name:example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target:/
spec:
ingressClassName:nginx
tls:
-hosts:
-api.example.com
secretName:api-tls-secret
rules:
-host:api.example.com
http:
paths:
-path:/v1
pathType:Prefix
backend:
service:
name:api-service-v1
port:
number:80
-path:/v2
pathType:Prefix
backend:
service:
name:api-service-v2
port:
number:80第四层：存储原理
4.1 Kubernetes 存储抽象层级
┌─────────────────────────────────────────────────────────────┐
│ 存储抽象层级 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Pod │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ VolumeMount: /data │ │ │
│ │ │ mountPath: /data │ │ │
│ │ │ name: data-volume │ │ │
│ │ └───────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ Volumes: │ │ │
│ │ │ - name: data-volume │ │ │
│ │ │ persistentVolumeClaim: │ │ │
│ │ │ claimName: data-pvc │ │ │
│ │ └───────────────────────────────────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ 引用 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ PVC (PersistentVolumeClaim) │ │
│ │ │ │
│ │ apiVersion: v1 │ │
│ │ kind: PersistentVolumeClaim │ │
│ │ metadata: │ │
│ │ name: data-pvc │ │
│ │ spec: │ │
│ │ accessModes: ["ReadWriteOnce"] │ │
│ │ storageClassName: standard │ │
│ │ resources: │ │
│ │ requests: │ │
│ │ storage: 10Gi │ │
│ │ │ │
│ │ 作用：声明式存储需求 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ 绑定 / 动态创建 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ PV (PersistentVolume) │ │
│ │ │ │
│ │ apiVersion: v1 │ │
│ │ kind: PersistentVolume │ │
│ │ spec: │ │
│ │ capacity: │ │
│ │ storage: 10Gi │ │
│ │ accessModes: ["ReadWriteOnce"] │ │
│ │ storageClassName: standard │ │
│ │ persistentVolumeReclaimPolicy: Retain │ │
│ │ nfs: │ │
│ │ server: 192.168.1.100 │ │
│ │ path: /data │ │
│ │ │ │
│ │ 作用：存储资源的抽象 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ 由 StorageClass 动态创建 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ StorageClass │ │
│ │ │ │
│ │ apiVersion: storage.k8s.io/v1 │ │
│ │ kind: StorageClass │ │
│ │ metadata: │ │
│ │ name: standard │ │
│ │ provisioner: kubernetes.io/aws-ebs │ │
│ │ parameters: │ │
│ │ type: gp3 │ │
│ │ reclaimPolicy: Delete │ │
│ │ allowVolumeExpansion: true │ │
│ │ │ │
│ │ 作用：定义存储类型和动态创建策略 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ 调用 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CSI Driver (存储驱动) │ │
│ │ │ │
│ │ 实现 CSI 接口的存储系统： │ │
│ │ • AWS EBS CSI │ │
│ │ • GCE PD CSI │ │
│ │ • Ceph RBD CSI │ │
│ │ • NFS CSI │ │
│ │ • Local Path CSI │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘4.2 存储挂载流程
┌─────────────────────────────────────────────────────────────┐
│ 存储挂载完整流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 1: PVC 创建 │ │
│ │ 用户创建 PVC，请求存储资源 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 2: PV 绑定或动态创建 │ │
│ │ • 静态绑定：找到匹配的 PV │ │
│ │ • 动态创建：StorageClass 调用 CSI 创建 PV │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 3: Scheduler 调度 Pod │ │
│ │ 考虑 PV 所在节点（Local PV）或区域（云盘） │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 4: AttachDetach Controller │ │
│ │ • 调用 CSI 将存储卷 Attach 到节点 │ │
│ │ • 云盘：将磁盘挂载到虚拟机 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 5: Kubelet 等待卷 Attach 完成 │ │
│ │ 检查 VolumeAttached 状态 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 6: Kubelet 调用 CSI Node Stage │ │
│ │ • 格式化文件系统（首次） │ │
│ │ • 挂载到临时目录 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 7: Kubelet 调用 CSI Node Publish │ │
│ │ • 将卷挂载到 Pod 目录 │ │
│ │ • /var/lib/kubelet/pods/<pod-id>/volumes/... │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Step 8: Container 启动 │ │
│ │ • 通过 bind mount 将目录挂载到容器 │ │
│ │ • 容器内可访问存储 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘4.3 常见存储类型对比
| 类型 | 访问模式 | 特点 | 适用场景 |
|---|---|---|---|
| emptyDir | ReadWriteOnce | Pod 内临时存储，Pod 删除数据丢失 | 缓存、临时文件 |
| hostPath | ReadWriteOnce | 节点本地存储 | 日志、监控数据 |
| Local PV | ReadWriteOnce | 节点本地存储，Pod 调度到固定节点 | 数据库、高性能存储 |
| NFS | ReadWriteMany | 网络文件系统，多节点共享 | 共享文件、静态资源 |
| Cloud Disk | ReadWriteOnce | 云厂商块存储 | 数据库、有状态应用 |
| Ceph RBD | ReadWriteOnce | 分布式块存储 | 高可用存储 |
第五层：服务治理原理
5.1 服务网格架构（Istio）
┌─────────────────────────────────────────────────────────────┐
│ Istio 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 控制平面（Istiod） │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Pilot │ │ Citadel │ │ Galley │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ 流量管理 │ │ 证书管理 │ │ 配置验证 │ │ │
│ │ │ 路由规则 │ │ mTLS │ │ 入站配置 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ 统一功能： │ │
│ │ • 接收配置（VirtualService、DestinationRule） │ │
│ │ • 转换为 Envoy 配置（xDS API） │ │
│ │ • 下发给所有 Sidecar │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ xDS API（gRPC） │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据平面（Envoy Sidecar） │ │
│ │ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ Service A Pod │ │ Service B Pod │ │ │
│ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ │
│ │ │ │ Application │ │ │ │ Application │ │ │ │
│ │ │ │ Container │ │ │ │ Container │ │ │ │
│ │ │ └─────────────┘ │ │ └─────────────┘ │ │ │
│ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ │
│ │ │ │ Envoy │ │ │ │ Envoy │ │ │ │
│ │ │ │ Sidecar │◄─┼─────┼─│ Sidecar │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ • 代理流量 │ │ │ │ • 代理流量 │ │ │ │
│ │ │ │ • 负载均衡 │ │ │ │ • 负载均衡 │ │ │ │
│ │ │ │ • 熔断降级 │ │ │ │ • 熔断降级 │ │ │ │
│ │ │ │ • mTLS加密 │ │ │ │ • mTLS加密 │ │ │ │
│ │ │ │ • 链路追踪 │ │ │ │ • 链路追踪 │ │ │ │
│ │ │ └─────────────┘ │ │ └─────────────┘ │ │ │
│ │ └─────────────────┘ └─────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘5.2 流量拦截原理
┌─────────────────────────────────────────────────────────────┐
│ Envoy 流量拦截机制 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Pod 内 iptables 规则（由 istio-init 容器设置）： │
│ │
│ 出站流量拦截： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 应用容器 → 调用外部服务 │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ iptables REDIRECT → Envoy (15001端口) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ Envoy 决定路由（应用 VirtualService 规则） │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ 发送到目标服务 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 入站流量拦截： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 外部请求 → 到达 Pod │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ iptables REDIRECT → Envoy (15006端口) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ Envoy 处理（mTLS 解密、认证、授权） │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ 转发到应用容器 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ iptables 规则示例： │
│ -A ISTIO_OUTPUT -p tcp -j REDIRECT --to-ports 15001 │
│ -A ISTIO_INPUT -p tcp -j REDIRECT --to-ports 15006 │
│ │
└─────────────────────────────────────────────────────────────┘5.3 流量治理能力
| 能力 | 实现方式 | 配置资源 |
|---|---|---|
| 负载均衡 | Envoy 内置算法 | DestinationRule |
| 金丝雀发布 | 权重路由 | VirtualService |
| 熔断 | 连接池、离群实例检测 | DestinationRule |
| 限流 | 本地限流、全局限流 | EnvoyFilter |
| 重试 | 失败重试策略 | VirtualService |
| 超时 | 请求超时设置 | VirtualService |
| 故障注入 | 延迟、中止 | VirtualService |
| 流量镜像 | 镜像到测试服务 | VirtualService |
第六层：可观测性原理
6.1 可观测性三支柱
┌─────────────────────────────────────────────────────────────┐
│ 可观测性三支柱 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Metrics（指标监控） │ │
│ │ │ │
│ │ 回答：系统现在怎么样？ │ │
│ │ │ │
│ │ 数据类型： │ │
│ │ • Counter（计数器）：请求总数、错误总数 │ │
│ │ • Gauge（仪表）：当前连接数、内存使用 │ │
│ │ • Histogram（直方图）：请求延迟分布 │ │
│ │ • Summary（摘要）：分位数统计 │ │
│ │ │ │
│ │ 典型技术栈： │ │
│ │ Prometheus + Grafana + AlertManager │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Tracing（链路追踪） │ │
│ │ │ │
│ │ 回答：请求经过了哪些服务？ │ │
│ │ │ │
│ │ 核心概念： │ │
│ │ • Trace：一次完整请求链路 │ │
│ │ • Span：链路中的单个操作 │ │
│ │ • SpanContext：跨服务传递的上下文 │ │
│ │ │ │
│ │ 典型技术栈： │ │
│ │ Jaeger / Zipkin / SkyWalking / OpenTelemetry │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Logging（日志） │ │
│ │ │ │
│ │ 回答：系统发生了什么？ │ │
│ │ │ │
│ │ 日志级别： │ │
│ │ DEBUG → INFO → WARN → ERROR → FATAL │ │
│ │ │ │
│ │ 结构化日志：JSON 格式，便于检索分析 │ │
│ │ │ │
│ │ 典型技术栈： │ │
│ │ ELK (Elasticsearch + Logstash + Kibana) │ │
│ │ 或 Loki + Promtail + Grafana │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘6.2 Prometheus 监控原理
┌─────────────────────────────────────────────────────────────┐
│ Prometheus 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Prometheus Server │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ Retrieval (采集组件) │ │ │
│ │ │ • 服务发现（Kubernetes SD） │ │ │
│ │ │ • Pull 模式拉取指标 │ │ │
│ │ │ • 配置抓取规则（scrape_configs） │ │ │
│ │ └───────────────────────────────────────────────┘ │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ TSDB (时序数据库) │ │ │
│ │ │ • 本地存储时序数据 │ │ │
│ │ │ • 支持远程存储（Thanos、VictoriaMetrics） │ │ │
│ │ └───────────────────────────────────────────────┘ │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ PromQL (查询引擎) │ │ │
│ │ │ • 时序数据查询语言 │ │ │
│ │ │ • 支持聚合、函数、操作符 │ │ │
│ │ └───────────────────────────────────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ Pull │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Exporters / 应用暴露的 /metrics │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Node │ │ kube-state- │ │ 应用自身 │ │ │
│ │ │ Exporter │ │ metrics │ │ /metrics │ │ │
│ │ │ :9100 │ │ │ │ │ │ │
│ │ │ │ │ Pod/Deploy │ │ 业务指标 │ │ │
│ │ │ 节点指标 │ │ 状态指标 │ │ │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 指标格式： │
│ http_requests_total{method="GET",path="/api"} 1234 │
│ ^指标名称 ^标签（维度） ^值 │
│ │
└─────────────────────────────────────────────────────────────┘6.3 链路追踪原理
┌─────────────────────────────────────────────────────────────┐
│ 分布式链路追踪原理 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 请求链路示例： │
│ Client → Gateway → Service A → Service B → DB │
│ │
│ Trace 结构： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Trace ID: abc123 (全链路唯一标识) │ │
│ │ │ │
│ │ Span 1: Gateway │ │
│ │ ├── trace_id: abc123 │ │
│ │ ├── span_id: span1 │ │
│ │ ├── parent_span_id: null │ │
│ │ ├── operation: "HTTP GET /api" │ │
│ │ ├── start_time: 100ms │ │
│ │ └── duration: 50ms │ │
│ │ │ │
│ │ Span 2: Service A │ │
│ │ ├── trace_id: abc123 │ │
│ │ ├── span_id: span2 │ │
│ │ ├── parent_span_id: span1 │ │
│ │ └── ... │ │
│ │ │ │
│ │ Span 3: Service B │ │
│ │ ├── trace_id: abc123 │ │
│ │ ├── span_id: span3 │ │
│ │ ├── parent_span_id: span2 │ │
│ │ └── ... │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 时间线可视化（瀑布图）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Span 1: [=====================================] │ │
│ │ Span 2: [============================] │ │
│ │ Span 3: [==================] │ │
│ │ Span 4: [==========] │ │
│ │ 0ms 20ms 40ms 60ms 80ms │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 上下文传递（W3C Trace Context 标准）： │
│ traceparent: 00-abc123-span1-01 │
│ ↑ ↑ ↑ ↑ │
│ 版本 TraceID SpanID 采样标志 │
│ │
└─────────────────────────────────────────────────────────────┘附录：快速上手实验清单
环境搭建
# 方式1：minikube（推荐入门）
minikube start --driver=docker --cpus=4 --memory=8192
# 方式2：kind（Kubernetes in Docker）
kind create cluster --config kind-config.yaml
# 方式3：k3s（轻量级 Kubernetes）
curl -sfL https://get.k3s.io | sh -核心实验清单
实验1：容器基础
# 1. 运行容器
docker run -d --name nginx -p 8080:80 nginx:alpine
# 2. 查看容器进程
docker top nginx
ps aux | grep nginx
# 3. 查看容器 Namespace
ls -la /proc/$(docker inspect --format '{{.State.Pid}}' nginx)/ns/
# 4. 查看容器 Cgroups
cat /sys/fs/cgroup/memory/docker/$(docker inspect --format '{{.Id}}' nginx)/memory.limit_in_bytes
# 5. 构建多阶段镜像
docker build -t myapp:v1 .
docker images myapp实验2：Kubernetes 核心操作
# 1. 部署应用
kubectl create deployment nginx --image=nginx:alpine --replicas=3
# 2. 暴露服务
kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort
# 3. 扩缩容
kubectl scale deployment nginx --replicas=5
kubectl autoscale deployment nginx --cpu-percent=50 --min=3 --max=10
# 4. 滚动更新
kubectl set image deployment/nginx nginx=nginx:1.25
kubectl rollout status deployment/nginx
kubectl rollout history deployment/nginx
kubectl rollout undo deployment/nginx
# 5. 查看资源
kubectl get pods -o wide
kubectl describe pod <pod-name>
kubectl logs <pod-name> -f
kubectl exec -it <pod-name> -- /bin/sh实验3：网络与服务
# 1. 创建 Service
kubectl expose deployment nginx --name=nginx-svc --port=80
# 2. 创建 Ingress
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
spec:
rules:
- host: nginx.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
EOF
# 3. 查看 Endpoints
kubectl get endpoints nginx-svc
# 4. 测试网络连通性
kubectl run test --image=busybox --rm -it -- wget -qO- nginx-svc实验4：存储实验
# 1. 创建 PVC
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
EOF
# 2. 使用 PVC 的 Pod
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: test
image: busybox
command: ["sh", "-c", "echo 'hello' > /data/test.txt && sleep 3600"]
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
persistentVolumeClaim:
claimName: test-pvc
EOF实验5：监控部署
# 使用 Helm 安装 Prometheus Stack
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack
# 访问 Grafana
kubectl port-forward svc/prometheus-grafana 3000:80
# 用户名: admin, 密码: prom-operator实验6：服务网格
# 安装 Istio
curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=demo
# 部署示例应用
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
# 启用 Sidecar 注入
kubectl label namespace default istio-injection=enabled
# 配置 Ingress Gateway
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml总结：云原生技术原理学习路径
┌─────────────────────────────────────────────────────────────┐
│ 学习路径建议 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 第一阶段（1-2月）：基础入门 │
│ ├── Docker 容器操作 │
│ ├── Kubernetes 核心对象（Pod/Deployment/Service） │
│ ├── kubectl 命令行操作 │
│ └── 本地集群搭建（minikube） │
│ │
│ 第二阶段（2-4月）：原理深入 │
│ ├── 容器底层原理（Namespace/Cgroups） │
│ ├── Kubernetes 架构组件原理 │
│ ├── 网络/存储原理 │
│ └── 监控告警体系搭建 │
│ │
│ 第三阶段（4-6月）：进阶实践 │
│ ├── 服务网格（Istio） │
│ ├── CI/CD 流水线 │
│ ├── 安全加固（RBAC/NetworkPolicy） │
│ └── 性能调优与故障排查 │
│ │
│ 第四阶段（6月+）：专家进阶 │
│ ├── Kubernetes 源码阅读 │
│ ├── Operator 开发 │
│ ├── 平台工程 │
│ └── 云原生架构设计 │
│ │
└─────────────────────────────────────────────────────────────┘核心心法 ：
云原生技术的学习，要从"会用"到"懂原理"，再到"能设计"。
理解每一层的原理，才能在遇到问题时快速定位和解决。