引子：我们搭的其实不只是一个 Kubernetes 集群
从第一篇安装 Ubuntu 24.04 开始，到第十二篇做告警和故障注入，这个系列终于走到了最后一篇。
最开始，我给它起的名字是：
从零搭建一个单节点 K8S 可观测实验室。
现在回头看，这个名字其实已经有一点"装不下"它了。
因为经过前十二篇，我们搭起来的已经不只是一个 Kubernetes 集群，也不只是 Prometheus、Grafana、Loki、Tempo 这些可观测组件的集合。
它已经逐渐变成了一套完整的个人技术实验环境：
Hardware / VM
│
▼
Ubuntu / Linux
│
▼
Docker / containerd / CRI
│
▼
Kubernetes
│
├───────────────┐
│ │
▼ ▼
Application CI / CD
│ │
│ Jenkins / GitHub Actions
│ │
│ Harbor
│ │
└───────┬───────┘
│
▼
Observability
│
┌───────┼────────┐
▼ ▼ ▼
Metrics Logs Traces
│ │ │
Prometheus Loki Tempo
│ │ │
└───────┼────────┘
│
Grafana
│
▼
Alerting
│
▼
Troubleshooting
│
▼
Fault Recovery这套结构已经覆盖了现代云原生基础设施中的很多关键环节。Kubernetes 本身就是面向容器化工作负载的声明式、自动化平台，而它下面依赖 Linux、容器运行时和网络，上面又天然连接应用交付、可观测性和平台工程。
所以，如果现在让我重新定义这个实验室，我更愿意称它为：
一个属于自己的个人技术练兵场。
在这里可以学习 Linux，可以折腾虚拟化，可以研究 Docker 和 containerd，可以理解 Kubernetes，可以做网络和权限实验，可以搭 CI/CD，可以研究 Metrics、Logs、Traces，可以接 OpenTelemetry。
而在这个基础上，只要继续增加硬件和软件能力，它还完全可以继续向两个很有意思的方向生长：
AI Infra 和高性能网络。
这也是这篇总结真正想说的事情：
这个系列结束了，但这个实验室的价值，才刚刚开始。
回头看这十三篇，我们真正走过了什么？
先把整个系列完整放在这里。
| 篇章 | 文章 |
|---|---|
| 一 | 从零搭建一个单节点 K8S 可观测实验室（一）：从 Ubuntu 24.04 开始 ✅ |
| 二 | 从零搭建一个单节点 K8S 可观测实验室（二）：安装单节点 Kubernetes ✅ |
| 三 | 从零搭建一个单节点 K8S 可观测实验室（三）：安装 Prometheus + Grafana，看懂集群指标 ✅ |
| 四 | 从零搭建一个单节点 K8S 可观测实验室（四）：修复 kubectl exec 失败问题------一次 cri-dockerd Streaming API 排查 ✅ |
| 五 | 从零搭建一个单节点 K8S 可观测实验室（五）：安装 Loki + Fluent Bit，构建日志采集链路 ✅ |
| 六 | 从零搭建一个单节点 K8S 可观测实验室（六）：安装 Tempo + OpenTelemetry，构建链路追踪链路 ✅ |
| 七 | 从零搭建一个单节点 K8S 可观测实验室（七）：从一次 Pod 创建过程，看懂 Kubernetes 核心原理 ✅ |
| 八 | 从零搭建一个单节点 K8S 可观测实验室（八）：安装 Jenkins，把 CI 接进实验室 ✅ |
| 九 | 从零搭建一个单节点 K8S 可观测实验室（九）：GitHub Actions------用 Self-hosted Runner 自动部署 ✅ |
| 十 | 从零搭建一个单节点 K8S 可观测实验室（十）：加入 Harbor 镜像仓库，完善 Kubernetes 发布链路 ✅ |
| 十一 | 从零搭建一个单节点 K8S 可观测实验室（十一）：压测与 Grafana------让监控数据真正动起来 ✅ |
| 十二 | 从零搭建一个单节点 K8S 可观测实验室（十二）：告警与故障注入------从 Pending、Firing 到故障恢复 ✅ |
| 十三 | 从零搭建一个单节点 K8S 可观测实验室（十三）：总结------这个实验室如何服务工作、学习和开源项目 |
表面看，它是一条：
Ubuntu
↓
Kubernetes
↓
Prometheus / Grafana
↓
Loki
↓
Tempo / OpenTelemetry
↓
Jenkins
↓
GitHub Actions
↓
Harbor
↓
压测
↓
告警
↓
故障注入的安装路线。
但实际上，每往前一步，我们都多接触了一层系统。
第一篇看似只是在安装 Ubuntu，实际上碰到的是 Linux 这个所有上层软件最终依赖的基础平台。
第二篇安装 Kubernetes 后，我们开始面对 kube-apiserver、scheduler、controller、kubelet、容器运行时和 CNI。Kubernetes 官方架构本身就是由 control plane 和运行工作负载的 node 组成，而 Pod 最终还是运行在节点上的容器。
第四篇甚至尤其典型。
一个看似简单的：
kubectl exec失败，最后一路追到了：
kubectl
│
▼
kube-apiserver
│
▼
kubelet
│
▼
CRI / cri-dockerd
│
▼
Streaming API
│
▼
Container
这类问题恰恰说明了实验环境最大的价值。
正常的时候，我们看到的是命令；出问题的时候，我们才开始看到系统。
今天 Kubernetes 已经不再内置 dockershim，节点必须通过 CRI 对接符合要求的容器运行时；containerd 自身则内置 CRI 插件，由它接收 kubelet 的 CRI 请求并管理容器生命周期。也正因为存在这些明确的接口边界，我们才有机会沿着调用链逐层定位问题。
到了后面，可观测系统加入以后，实验室又多了一双"眼睛"。
Prometheus 负责采集和存储时间序列指标，并可以基于数据执行规则；Loki 是面向日志的聚合系统；Tempo 是分布式追踪后端；OpenTelemetry 则提供了生成、采集、处理和导出 traces、metrics、logs 的厂商中立框架。
于是我们开始能够从三个角度看同一个问题：
一个故障
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
Metrics Logs Traces
│ │ │
发生了吗？ 发生了什么？ 发生在哪里？
严重吗？ 为什么报错？ 哪一段最慢？再到 Jenkins、GitHub Actions 和 Harbor，实验室开始有了"发布能力"。
Jenkins Pipeline 可以把 Build、Test、Deploy 等阶段以 Pipeline as Code 的方式组织起来；GitHub Self-hosted Runner 则允许自己管理执行 Actions Job 的机器和环境；Harbor 不只是一个镜像存储点，也可以继续扩展漏洞扫描等供应链能力。
于是，一条真正的软件生命周期链路开始出现：
Developer
│
▼
Git
│
▼
CI Pipeline
│
├── Build
├── Test
└── Image Build
│
▼
Harbor
│
▼
Kubernetes
│
▼
Application
│
┌─────┼─────┐
▼ ▼ ▼
Metrics Logs Traces
│ │ │
└─────┼─────┘
▼
Alert
│
▼
Troubleshooting
│
▼
Fault Recovery这里有一个很重要的变化：
我们不再只是"把 Kubernetes 装起来了"。
我们第一次从头到尾走了一遍：
代码如何进入系统，系统如何运行，运行状态如何被观察，异常如何被发现，故障又如何被定位和恢复。
这才是前十二篇真正串起来之后的意义。
它真正能服务什么：工作、学习、开源项目和长期技术积累
一个实验室到底有没有价值，不在于里面安装了多少软件，而在于它能不能反复使用。
我觉得这套环境最有价值的地方，可以归纳成四件事。
第一，它可以服务工作
工作中最麻烦的问题往往不是"这个命令怎么写"，而是：
为什么在我的环境正常？
为什么在服务器不正常？
为什么容器里不正常？
为什么到了 Kubernetes 又不正常？
为什么 Pod Running 但是业务不可用？
为什么请求超时却看不到明显报错？这些问题通常横跨多个层次：
Application
↓
Container
↓
Kubernetes
↓
Linux
↓
Network
↓
Hardware有这样一个自己的环境，就意味着很多问题不需要直接在真实业务环境里试。
可以先缩小问题。
例如怀疑容器运行时：
Docker?
containerd?
CRI?
kubelet?怀疑网络：
Pod IP?
Service?
DNS?
CNI?
NetworkPolicy?
Host Network?怀疑性能：
CPU?
Memory?
Disk?
Network?
Application?然后通过 Metrics、Logs 和 Traces 一层层排除。
OpenTelemetry 的核心价值之一正是让不同遥测信号共享统一的资源属性，从而更容易把来自同一个 Kubernetes Pod 的指标、日志和链路关联起来。
所以，这个实验室可以成为：
工作问题的最小复现环境和技术方案验证环境。
它不替代生产环境，但可以显著降低"直接在生产上猜"的概率。
第二，它可以服务学习
以前学习某个技术，常常是一条线：
看书
↓
看教程
↓
记命令
↓
过几个月
↓
忘了有实验室以后，学习方式可以变成：
看到概念
↓
自己部署
↓
自己观察
↓
主动破坏
↓
查看现象
↓
定位原因
↓
修复
↓
形成理解这种学习方式特别适合 Kubernetes，因为 Kubernetes 自身强调 desired state 和 controller 驱动的状态协调：你声明期望状态，控制器不断推动实际状态向期望状态靠近。工作负载控制器会持续确保"正确数量、正确类型"的 Pod 运行。
所以第七篇从 Pod 创建过程出发，其实是这个系列一个很重要的转折点。
我们开始从：
kubectl apply向下追：
YAML
│
▼
API Server
│
▼
etcd
│
▼
Controller
│
▼
Scheduler
│
▼
kubelet
│
▼
CRI
│
▼
Container Runtime
│
▼
Linux这时候 Kubernetes 就不再是一个"需要背很多 YAML 的软件"。
而变成了一套可以被拆解、观察和理解的系统。
第三，它可以服务开源项目
很多个人项目最后停留在：
GitHub Repository代码写完了。
README 写完了。
然后结束。
但真正的软件工程能力，还包括：
Code
↓
Build
↓
Test
↓
Image
↓
Registry
↓
Deploy
↓
Observe
↓
Alert
↓
Upgrade
↓
RollbackJenkins 可以把流水线本身代码化，GitHub Actions 可以利用自己的 Self-hosted Runner 执行工作流，而 Harbor 可以作为自己的 Artifact / Image Registry。
这意味着以后做一个开源项目时，可以直接把它丢进这个实验室：
GitHub
│
▼
GitHub Actions / Jenkins
│
▼
Build & Test
│
▼
Docker Image
│
▼
Harbor
│
▼
Kubernetes
│
▼
Prometheus / Loki / Tempo这样做出来的就不只是一份 source code。
而是一个：
真正可构建、可发布、可运行、可观察的软件系统。
第四，它可以服务长期的个人技术积累
这是我现在反而觉得最重要的一点。
技术学习很容易碎片化：
今天研究 Linux。
下周学 Docker。
过一阵子学 Kubernetes。
后来又做 Prometheus。
再之后碰 AI、GPU、DPDK。
每个东西单独看，都好像是一个新领域。
但如果始终围绕同一个实验室扩展，它们会慢慢连起来：
Linux
│
├── Namespace
├── cgroup
├── Networking
├── Storage
└── Security
│
▼
Container
│
▼
Kubernetes
│
┌────┼───────────┐
│ │ │
▼ ▼ ▼
CI/CD Observability Infrastructure
│
┌──────┴──────┐
▼ ▼
AI Infra High Performance
Networking最终积累下来的就不只是知识点，而是一张越来越完整的技术地图。
从这里往外看，这个实验室至少可以长出七条技术路线
这个系列到这里结束，不意味着环境没有东西可以继续玩。
恰恰相反。
现在这个实验室更像是搭好了一个"底座"。
往哪个方向走，都可以从这里继续长。
我觉得至少有七条很清晰的路线。
| 方向 | 现在已经具备的基础 | 可以进一步探索 |
|---|---|---|
| Ubuntu / Linux / VM | Ubuntu 24.04、单节点环境 | systemd、进程、Namespace、cgroup、KVM/QEMU、libvirt、NUMA、HugePages、性能调优 |
| Docker / Container | Docker、cri-dockerd、Kubernetes Container | containerd、runc、OCI、镜像分层、OverlayFS、Rootless Container、CRI |
| Kubernetes 生产化 | kubeadm 单节点集群 | HA、etcd、Worker Node、CNI、CSI、RBAC、NetworkPolicy、Ingress/Gateway API |
| 可观测生产化 | Prometheus、Grafana、Loki、Tempo、Fluent Bit、OTel | Alertmanager、Recording Rule、SLO、Long-term Storage、OTel Collector Pipeline、告警治理 |
| CI/CD 生产化 | Jenkins、GitHub Actions、Harbor | Pipeline as Code、Runner/Agent 池、GitOps、Argo CD、镜像扫描、SBOM、签名、发布策略 |
| AI Infra | Kubernetes + Observability | GPU、GPU Operator、Device Plugin、DRA、GPU Metrics、模型推理、分布式训练 |
| 高性能网络 | Linux + Kubernetes + CNI 基础 | eBPF、Cilium、Hubble、Multus、SR-IOV、DPDK、VPP、RDMA |
这些方向并不是硬凑出来的。
它们本身就在共享同一套底层能力。
Ubuntu / Linux / VM 方向
容器不是独立于 Linux 存在的魔法。Docker 创建容器时依赖 Linux namespace 提供隔离，同时利用 control groups 管理资源；Linux cgroup v2 本身就是内核提供的分层资源控制机制。
所以继续往下挖，就可以从：
Pod CPU Limit一路追到：
Kubernetes resources
↓
kubelet
↓
Container Runtime
↓
cgroup
↓
Linux Kernel甚至可以做非常具体的实验：
cat /proc/<pid>/cgroup看看容器进程究竟属于哪个 cgroup。
研究：
memory.max
cpu.max
cpuset.cpus再继续研究 NUMA、CPU isolation、HugePages。
Linux 内核官方文档本身就提供了 cgroup v2、CPU isolation 等机制；这些能力同时又会在虚拟化、高性能网络和 AI Infra 里再次出现。
虚拟化也可以继续。
Ubuntu 官方文档完整支持基于 QEMU/KVM 和 libvirt 构建虚拟机环境，甚至可以进一步研究 nested virtualization、HugePages 和设备直通。
这样一来，路线会变成：
Physical Machine
│
▼
KVM
│
▼
Virtual Machines
│
▼
Kubernetes
│
▼
Containers甚至还可以反过来玩 KubeVirt，把 VM 重新放回 Kubernetes API 体系中管理。KubeVirt 会向 Kubernetes 增加 VM 相关资源，让虚拟机也可以像其他 Kubernetes 对象一样被声明和操作。
这时候，"虚拟机"和"容器"就不再是两个互不相关的概念。
Docker / Container 方向
第四篇已经因为 cri-dockerd 带我们第一次碰到了 Kubernetes 与 Runtime 的边界。
以后完全可以单独再搭一个 containerd 节点：
现在
Kubernetes
│
▼
cri-dockerd
│
▼
Docker对比：
Kubernetes
│
▼
CRI
│
▼
containerd
│
▼
OCI Runtime
│
▼
Linux Kernelcontainerd 官方文档明确说明，它的 CRI 插件直接处理 kubelet 发来的 CRI 请求，并负责容器与镜像生命周期。
这样可以真正把 Docker、containerd、runc、OCI、CRI 这些经常混在一起的概念拆开。
Kubernetes 生产化方向
目前这个单节点实验室最大的优点恰恰也是最大的限制：
Everything
│
▼
One Node实验很方便。
但它不是生产架构。
Kubernetes 官方生产环境指南明确指出，单机 control plane 不具备高可用性；生产环境通常需要考虑控制面复制、API Server 负载均衡、足够的 Worker Node、扩容能力和故障恢复。kubeadm 官方 HA 方案则支持 stacked etcd 和 external etcd 两种主要拓扑。
因此有一天完全可以把它升级成：
Load Balancer
│
┌──────────┼──────────┐
▼ ▼ ▼
Control Plane Control Plane Control Plane
│ │ │
└──────── etcd ───────┘
┌──────────┼──────────┐
▼ ▼ ▼
Worker Worker Worker然后继续做：
Node Failure
etcd Failure
Control Plane Failure
Rolling Upgrade
Drain / Cordon
PodDisruptionBudget
Affinity
Anti-Affinity
Topology Spread再加上生产网络和安全能力。
Kubernetes 的 NetworkPolicy 可以在 L3/L4 层约束 Pod 与其他实体之间允许的流量，而 RBAC 则负责通过 Kubernetes API 动态配置授权策略。
存储也可以从现在的简单本地存储，逐渐过渡到：
Application
│
▼
PVC
│
▼
StorageClass
│
▼
CSI
│
▼
Storage BackendKubernetes 的 StorageClass 本身就是用来描述不同存储类别和动态 provisioner 的抽象。
可观测生产化方向
现在我们已经有：
Metrics → Prometheus
Logs → Loki
Traces → Tempo但"装好三个 backend"只是第一步。
OpenTelemetry 对 observability signals 的定义已经覆盖 metrics、logs、traces 等遥测数据，而 Collector 可以作为统一的接收、处理、转换和导出层。
以后可以继续演进：
Applications
│
▼
OpenTelemetry SDK / Agent
│
▼
OTel Collector
│
┌───┼───────────┐
▼ ▼ ▼
Metrics Logs Traces
│ │ │
▼ ▼ ▼
Prom Loki Tempo
│
▼
Grafana再进一步研究：
Sampling
Cardinality
Retention
Recording Rules
Alert Rules
SLO / SLI
Trace → Log correlation
Metric → Trace exemplar
Long-term storageTempo 官方文档就支持把 trace 与 logs、metrics 建立关联，而 Prometheus 可以通过 recording rules 预计算时间序列、通过 alerting rules 生成告警。
第十二篇也可以继续延伸。
现在我们已经经历：
Normal
↓
Fault Injection
↓
Pending
↓
Firing
↓
Troubleshooting
↓
Fault Recovery以后真正生产化的目标应该是：
Symptom
↓
Prometheus Rule
↓
Alertmanager
↓
Group / Deduplicate / Silence / Inhibit
↓
Route
↓
Human / AutomationAlertmanager 官方设计本身就包含去重、分组、路由、silence 和 inhibition。
这时候，"监控"才开始变成真正的 Observability + Reliability Engineering。
CI/CD 生产化方向
目前我们的发布链路大致是：
GitHub
│
▼
GitHub Actions / Jenkins
│
▼
Docker Build
│
▼
Harbor
│
▼
kubectl apply
│
▼
Kubernetes后面一个很自然的方向就是 GitOps。
例如：
Developer
│
▼
Source Repo
│
▼
CI
│
├── Test
├── Build
└── Push Image
│
▼
Config Repo
│
▼
Argo CD
│
▼
KubernetesArgo CD 的核心模型就是：Git 中保存应用的目标状态，Argo CD 比较 target state 和 live state，再进行同步。
这会把：
CI 直接操作 Kubernetes逐渐变成：
CI 负责生成 Artifact
CD 负责让 Cluster 收敛到 Git Desired State然后再继续加入：
Image Scan
SBOM
Image Signing
Policy
Progressive Delivery
Rollback甚至 Self-hosted Runner 自身也可以 Kubernetes 化。GitHub 官方已经提供 Actions Runner Controller 来在 Kubernetes 中管理 Runner Scale Sets；Jenkins 同样支持基于 controller/agents 模型，并可以在 Kubernetes 中按需启动 agents。
于是一个很有意思的闭环出现了：
以前：
CI 帮助部署 Kubernetes
以后：
Kubernetes 自己也可以承载 CI这就是平台化。
加上一块 GPU 之后，实验室可以真正进入 AI Infra
这里单独拿出来说。
因为之前提到：
是不是增加 GPU，就可以学习 GPU 资源分配和 AI 部署？
答案是：
是，而且这条路线比单纯"跑一个 AI 模型"要有意思得多。
但需要补充一个前提。
如果 Ubuntu Kubernetes Node 直接运行在物理机上，那么 GPU 需要先被 Linux 正确识别。
如果 Kubernetes Node 本身运行在 VM 里，则物理 GPU 还需要先通过 PCI passthrough、vGPU 或其他虚拟化机制暴露给 Guest OS；GPU 在 Guest Linux 中不可见的话，Kubernetes 自然也无从调度。Ubuntu 的 QEMU/KVM 文档已经包含 GPU virtualization 和 passthrough 相关能力。
GPU 真正进入 Kubernetes 后，技术链路会变成：
Physical GPU
│
▼
NVIDIA Driver
│
▼
NVIDIA Container Toolkit
│
▼
GPU Device Plugin / DRA Driver
│
▼
Kubernetes Scheduler
│
▼
Pod
│
▼
CUDA / PyTorch / Model Server
传统 Kubernetes GPU 调度通过 Device Plugin Framework 暴露 GPU、NIC、FPGA 等特殊硬件资源，然后 Pod 可以声明所需的 GPU 资源。
例如经典方式：
resources:
limits:
nvidia.com/gpu: 1加上 GPU 以后，就可以实验真正的资源调度问题：
Pod A needs GPU
Pod B needs GPU
│
▼
Which GPU?
Which Node?
Can GPU be shared?
How to isolate?
How to observe?
How to schedule fairly?而到了 2026 年，这件事已经比最初的 nvidia.com/gpu: 1 更值得研究。
Kubernetes 的 Dynamic Resource Allocation，DRA 已经在 Kubernetes v1.35 进入 stable；它允许工作负载通过 DeviceClass、ResourceClaim、ResourceClaimTemplate 等对象，更灵活地声明和分配 GPU 等附加设备。
概念开始从：
我要 1 块 GPU走向：
我要一类满足特定条件的 accelerator
│
▼
DeviceClass
│
▼
ResourceClaim
│
▼
Kubernetes Allocation
│
▼
PodNVIDIA 目前也已经提供面向 Kubernetes DRA 的 GPU Driver，并将 GPU allocation 和更高级的 GPU 拓扑能力接入 DRA。
这就是非常标准的 AI Infra 问题了。
继续往下，还可以研究 GPU 共享。
NVIDIA GPU Operator 支持 GPU time-slicing；需要注意，time-slicing 本质上是在同一物理 GPU 上复用运行时间，并不像 MIG 那样提供内存和故障隔离。
于是可以实验：
Dedicated GPU
vs
Time Slicing
vs
MIG然后开始问真正的平台问题：
一块 GPU 应该给谁？
GPU 利用率是多少？
显存是不是浪费？
多个 workload 怎么共享？
推理 workload 和训练 workload 怎么隔离？
不同 GPU 型号怎么调度？更有意思的是，我们之前搭的 Prometheus + Grafana 在这里完全不需要推倒重来。
NVIDIA DCGM Exporter 可以直接将 GPU 遥测信息以 Prometheus exposition format 暴露出来，从而让已有 Prometheus 抓取，再由 Grafana 展示。
于是已有可观测链路可以直接扩展成：
CPU Metrics ───────────┐
Memory Metrics ────────┤
Network Metrics ───────┤
Kubernetes Metrics ────┤
▼
GPU Utilization ─── Prometheus ─── Grafana
GPU Memory ────────────┤
GPU Temperature ───────┤
GPU Power ─────────────┘这其实非常漂亮。
因为你会突然发现：
前十二篇搭的东西不是 AI Infra 的"前置废课"，而恰恰就是 AI Infra 的基础设施。
再往应用层走，就可以开始做模型推理：
Client
│
▼
Gateway
│
▼
Model Serving
│
▼
Kubernetes Pod
│
▼
GPU截至 2026 年，Kubernetes 社区已经有专门面向生成式 AI 推理的 Gateway API Inference Extension，用模型服务的 metrics、capabilities 等信息辅助请求路由和负载均衡。
再往训练方向走，则可以研究：
Dataset
│
▼
Distributed Training
│
┌─┴───────────┐
▼ ▼
GPU Node A GPU Node B
│ │
└──── Network ┘Kubeflow Trainer 目前就是 Kubernetes-native 的分布式 AI Training 平台，支持 PyTorch、JAX、DeepSpeed、Hugging Face、Megatron 等多种训练框架，并面向多节点、多 GPU 场景。
到这里，技术地图就已经变成：
AI Application
│
▼
Model Serving
│
▼
Kubernetes
│
┌─────────┼─────────┐
▼ ▼ ▼
Scheduler DRA Network
│ │ │
└───── GPU ─────────┘
│
▼
NVIDIA Driver
│
▼
GPU然后旁边还有我们已经搭好的：
Prometheus
Grafana
Loki
Tempo
OpenTelemetry
CI/CD
Harbor这就是一个小型 AI Infrastructure Lab 的雏形。
再加高性能 NIC，这个实验室又可以从云原生走到高性能网络
GPU 是一条路线。
另一条我觉得同样很值得保留，而且与 AI Infra 最终甚至会汇合的路线，就是：
High Performance Networking。
目前 Kubernetes 的普通网络路径大致可以抽象成：
Application
│
▼
Socket
│
▼
Linux TCP/IP Stack
│
▼
CNI / veth / Routing
│
▼
Kernel
│
▼
NIC
首先可以从 eBPF 开始。
例如把 CNI 换成 Cilium。
Cilium 基于 eBPF 实现 Kubernetes 网络、负载均衡、安全策略和可观测能力；Hubble 则进一步提供 cluster-wide 的网络和安全可见性。
这样一来，我们已有的 Observability 又可以向网络层继续向下延伸：
Application Observability
│
Metrics / Logs / Traces
│
▼
OpenTelemetry
│
│
---------│-----------------
│
▼
Network Observability
│
Hubble
│
▼
eBPF
│
▼
Linux Kernel这非常适合研究：
Pod 到底和谁通信？
DNS 请求去了哪里？
NetworkPolicy 为什么把流量挡掉了？
Service 转发发生在哪里？
TCP 重传从哪里出现？再向下，可以研究 SR-IOV。
Kubernetes 的 Device Plugin Framework 本身不仅能用于 GPU，也能用于高性能 NIC、InfiniBand 等硬件。
SR-IOV Network Device Plugin 可以发现并向 Kubernetes 暴露 PF、VF 等网络资源，再配合 Multus 和 SR-IOV CNI 把相应设备交给 Pod。
于是网络路径会出现另一种形态：
Physical NIC
│
┌──────┼──────┐
▼ ▼ ▼
VF1 VF2 VF3
│ │ │
▼ ▼ ▼
Pod A Pod B Pod C这就已经非常接近 NFV、Telco Cloud、高性能网络和 AI Cluster 中会遇到的真实问题了。
再继续就是 DPDK。
DPDK 的 Poll Mode Driver 可以在 userspace 直接处理 NIC RX/TX descriptors，以轮询方式进行高速收发。
于是可以比较：
传统网络路径
Application
│
▼
Linux Socket
│
▼
Kernel Network Stack
│
▼
Driver
│
▼
NIC和：
DPDK Path
Application
│
▼
DPDK / PMD
│
▼
Userspace
│
▼
NIC Queue
│
▼
NIC再进一步加入 VPP。
FD.io VPP 是运行在 Linux userspace 的高性能 L2-L4 网络栈，并可以结合 DPDK；VPP 官方也提供了 Kubernetes 集成场景。
到那时候，实验室的方向就可能变成：
Kubernetes
│
▼
Multus
│
▼
SR-IOV
│
▼
DPDK / VPP
│
▼
High Performance NIC有意思的是，这条路线最终还可能和前面的 AI Infra 汇合。
因为分布式 AI 训练最终也是一个：
GPU
│
GPU
│
GPU之间大量交换数据的问题。
于是后面自然会碰到：
GPU Scheduling
+
NUMA
+
PCIe Topology
+
High Performance NIC
+
RDMA
+
Distributed TrainingKubeflow Trainer 本身已经支持 multi-node、multi-GPU 训练，而 Linux 内核也有面向 RDMA/InfiniBand 资源的控制机制；换句话说，AI Infra 与高性能网络从来就不是两个完全分开的技术岛。
于是从今天这个小小的单节点集群向前看，甚至可以画出这样一条路线：
Ubuntu / Linux
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Container Networking Virtualization
│ │ │
▼ ▼ ▼
Kubernetes eBPF KVM/QEMU
│ │
┌───────┼───────┐ │
▼ ▼ ▼ ▼
Observability CI/CD GPU SR-IOV
│ │ │
▼ ▼ ▼
OpenTelemetry AI Infra DPDK / VPP
│ │
└───┬───┘
▼
Distributed AI /
High Performance Infra这也是为什么我现在觉得：
"单节点 K8S 可观测实验室"只是它的起点，而不是它最终的边界。
但也要清楚：个人练兵场不等于生产环境
写到这里，很容易产生一种错觉：
我们已经 Prometheus、Grafana、Loki、Tempo、CI/CD、Harbor 都有了，是不是已经接近一个生产 Kubernetes 平台了？
还不是。
这一点反而要在系列最后明确说清楚。
这个实验室最大的设计目标是：
低成本
+
可重复
+
可破坏
+
可观察
+
容易恢复而生产环境首先要求的是：
Availability
Security
Scalability
Durability
Governance
Operational Reliability单节点最大的限制就是：
Node Down
│
▼
Everything Down而 Kubernetes 官方生产指南明确建议，对于需要长期运行和高可用的环境，应考虑复制 control plane、分离控制面和 worker、为 API Server 做负载均衡，并拥有足够的 worker capacity；kubeadm 的 stacked HA 拓扑也建议至少三个 control plane nodes。
同样的区别也存在于 Observability。
单机 Loki 可以很好地学习 LogQL 和日志采集。
但 Loki 官方本身支持从 single binary 到 simple scalable 再到 microservices 的不同部署模式；真正生产化还需要继续考虑对象存储、查询规模、tenant、retention 和容量规划。
Tempo 也是如此，可以从简单部署扩展到更完整的分布式架构。
CI/CD 同样如此。
个人 Self-hosted Runner 非常适合实验，但 GitHub 官方特别提醒，Self-hosted Runner 使用时要注意仓库访问边界；公开仓库的 fork / pull request 可能导致不可信代码在自己的 Runner 上运行，因此安全隔离是生产化时必须重新设计的问题。
Harbor 生产化也不只是：
docker push
docker pull而会继续涉及漏洞扫描、复制、权限、生命周期、备份、监控等能力。Harbor 当前可以通过 Trivy 做 Artifact 漏洞扫描，并且自身也可以暴露 Prometheus 风格的运行指标。
所以这个实验室真正正确的定位不是：
"在家搭了一个生产 Kubernetes。"
而应该是：
"我拥有了一个可以用生产问题来训练自己的非生产环境。"
我觉得这两句话区别非常大。
在生产环境里：
不要随便动。在实验室里：
就是要动。生产最怕：
挂了。实验室反而应该主动：
把它搞挂。例如：
删一个 Pod
停 kubelet
打满 CPU
吃光 Memory
制造 Pending
写错镜像
断掉网络
改错 Service
制造 Alert
让 Trace 变慢
模拟 Node NotReady然后问自己：
我能不能先从 Grafana 看到异常？
能不能从 Prometheus 找到 symptom？
能不能从 Logs 找到 error？
能不能从 Trace 找到具体调用？
能不能用 kubectl 找到 Kubernetes 状态变化？
能不能继续下沉到 kubelet / runtime / Linux？
最后能不能恢复？这才是实验室真正应该训练的能力。
不是：
"我会不会安装这个软件。"
而是：
"当系统不正常时，我能不能理解它为什么不正常。"
写在最后：系列结束，但这个实验室真正留下的是一张技术地图
十三篇文章写到这里，这个系列就可以结束了。
暂时也不需要急着规划"第十四篇"。
因为我觉得现在最重要的，并不是为了继续写系列而硬找一个软件安装上去。
反而应该停下来看看：
我们到底得到了什么？
最开始，只有一台 Ubuntu。
Ubuntu 24.04然后我们安装了 Kubernetes。
Ubuntu
│
▼
Kubernetes接着加入可观测系统。
Kubernetes
│
├── Prometheus
├── Grafana
├── Loki
├── Fluent Bit
├── Tempo
└── OpenTelemetry然后加入 CI/CD。
GitHub
│
├── Jenkins
└── GitHub Actions
│
▼
Harbor
│
▼
Kubernetes再做压测、告警和故障注入。
Application
│
▼
Load Testing
│
▼
Metrics Change
│
▼
Grafana
│
▼
Alert
│
▼
Troubleshooting
│
▼
Fault Recovery走到今天，它已经可以被重新画成这样：
Personal Tech Lab
│
┌───────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
Linux / VM Containers Kubernetes
│ │ │
Ubuntu / KVM Docker / containerd kubeadm / CRI
│ │ │
└───────────────┬───────┴────────┬──────────────┘
│ │
▼ ▼
CI / CD Observability
│ │
Jenkins / GHA Prometheus
Harbor Grafana
│ Loki
│ Tempo
│ OpenTelemetry
│ │
└────────┬───────┘
│
▼
Real Workloads
│
┌─────────────┴─────────────┐
▼ ▼
AI Infra High Performance Network
│ │
GPU / DRA / AI eBPF / Cilium / SR-IOV
│ DPDK / VPP / RDMA
└─────────────┬─────────────┘
▼
Future Infrastructure Lab现在再回过头看，我觉得这个系列最大的收获，并不是我们"装了十二套东西"。
而是这些原本散落的技术第一次被放到了同一张地图上：
Linux
Virtualization
Container
Kubernetes
Networking
Storage
Security
CI/CD
Observability
OpenTelemetry
GPU
AI Infra
High Performance Networking以前可能觉得：
Linux 是 Linux。
Docker 是 Docker。
Kubernetes 是 Kubernetes。
Prometheus 是 Prometheus。
GPU 又是另外一个世界。
DPDK 更是完全不同的领域。
但真正把系统搭起来以后会发现，它们实际上层层相连。
一个 Pod 的 CPU Limit，最终会落到 Linux cgroup。
一个 Pod 的创建，最终需要 kubelet 通过 CRI 找到 container runtime。
一个 Service 的访问问题，会把你带到 Kubernetes Networking、CNI 和 Linux 网络栈。Kubernetes 官方自己就把 cluster networking 分为 container-to-container、Pod-to-Pod、Pod-to-Service 和 external-to-Service 等不同通信问题。
一个应用延迟问题，可能要同时看 Metrics、Logs 和 Traces。
一个 CI/CD 发布问题，会把 Git、Runner、Registry、Image 和 Kubernetes 串起来。
加一块 GPU，又会把 Linux Driver、Container Runtime、Kubernetes Scheduler、Device Plugin、DRA、Prometheus 和 AI Workload 全部重新串在一起。
再加高性能 NIC，网络、NUMA、PCIe、SR-IOV、DPDK、RDMA 和分布式 AI 又会继续连起来。Kubernetes 的设备模型本身已经面向 GPU、高性能 NIC、FPGA、InfiniBand 等专用硬件，这也是为什么这些扩展可以沿着同一套 Kubernetes 基础设施继续向前。
所以最后，我不太想用：
"我们终于学完 Kubernetes 了。"
来结束这个系列。
因为显然没有学完。
Kubernetes 也不可能通过十三篇文章"学完"。
我更愿意这样总结：
我们终于搭好了一个可以继续学习 Kubernetes，以及 Kubernetes 背后整个现代基础设施世界的地方。
它可以服务工作。
遇到问题，可以复现。
它可以服务学习。
看到概念，可以实验。
它可以服务开源项目。
写完代码，可以真正构建、发布、部署和观察。
它可以服务个人长期技术积累。
以后学 Linux，可以放进来。
学 containerd，可以放进来。
学 Cilium，可以放进来。
研究 GitOps，可以放进来。
有 GPU 了，可以做 AI Infra。
有高性能网卡了，可以做 SR-IOV、DPDK、VPP、RDMA。
甚至几年之后再回来看，也许这个实验室早就已经不是今天这个样子了。
但这正是它存在的意义。
一个好的实验室，不应该是搭完之后再也不动的"成品"。
它应该是一个可以随着自己的技术方向不断变化的环境。
今天，它是一个：
单节点 K8S 可观测实验室。
以后，它也许会变成：
Linux 实验室。
容器运行时实验室。
Kubernetes 平台实验室。
可观测性实验室。
CI/CD 与 GitOps 实验室。
AI Infra 实验室。
高性能网络实验室。
但名字其实已经不重要了。
因为到最后，它真正代表的是：
一个属于自己的个人技术练兵场。
可以拆。
可以改。
可以升级。
可以压测。
可以把它搞挂。
可以再把它救回来。
可以在这里理解那些生产环境里没有机会随便实验的东西。
也可以把工作中见到的问题、学习中遇到的概念、开源项目里的想法，一个一个搬进来验证。
从 Ubuntu 24.04 开始，我们最后搭出来的，并不是一个多么庞大的 Kubernetes 平台。
但它给了我们一样更重要的东西：
一个可以持续探索现代基础设施的起点。
所以，这个系列到这里，就正式结束吧。
不急着决定下一篇写什么。
以后真的遇到了值得研究的问题，或者想往某个方向继续走，再回来折腾它。
毕竟，真正的学习路线从来不会严格按照目录发生。
有时候是因为一个 kubectl exec 报错。
有时候是因为一个 Pod 一直 Pending。
有时候是因为 Grafana 上突然出现一条奇怪的曲线。
以后，也可能是因为加了一块 GPU。
或者插了一张支持 SR-IOV 的网卡。
然后，一个新的问题，又会把我们带到新的地方。
十三篇，系列完。
实验室，不完。