引子我们搭的其实不只是一个 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 / VMUbuntu 24.04、单节点环境systemd、进程、Namespace、cgroup、KVM/QEMU、libvirt、NUMA、HugePages、性能调优Docker / ContainerDocker、cri-dockerd、Kubernetes Containercontainerd、runc、OCI、镜像分层、OverlayFS、Rootless Container、CRIKubernetes 生产化kubeadm 单节点集群HA、etcd、Worker Node、CNI、CSI、RBAC、NetworkPolicy、Ingress/Gateway API可观测生产化Prometheus、Grafana、Loki、Tempo、Fluent Bit、OTelAlertmanager、Recording Rule、SLO、Long-term Storage、OTel Collector Pipeline、告警治理CI/CD 生产化Jenkins、GitHub Actions、HarborPipeline as Code、Runner/Agent 池、GitOps、Argo CD、镜像扫描、SBOM、签名、发布策略AI InfraKubernetes ObservabilityGPU、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 SetsJenkins 同样支持基于 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 OSGPU 在 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 AllocationDRA已经在 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 网络栈并可以结合 DPDKVPP 官方也提供了 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 capacitykubeadm 的 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 的网卡。然后一个新的问题又会把我们带到新的地方。十三篇系列完。实验室不完。 从零搭建一个单节点 K8S 可观测实验室（十三）：总结——这个实验室如何服务工作、学习和开源项目
引子我们搭的其实不只是一个 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 / VMUbuntu 24.04、单节点环境systemd、进程、Namespace、cgroup、KVM/QEMU、libvirt、NUMA、HugePages、性能调优Docker / ContainerDocker、cri-dockerd、Kubernetes Containercontainerd、runc、OCI、镜像分层、OverlayFS、Rootless Container、CRIKubernetes 生产化kubeadm 单节点集群HA、etcd、Worker Node、CNI、CSI、RBAC、NetworkPolicy、Ingress/Gateway API可观测生产化Prometheus、Grafana、Loki、Tempo、Fluent Bit、OTelAlertmanager、Recording Rule、SLO、Long-term Storage、OTel Collector Pipeline、告警治理CI/CD 生产化Jenkins、GitHub Actions、HarborPipeline as Code、Runner/Agent 池、GitOps、Argo CD、镜像扫描、SBOM、签名、发布策略AI InfraKubernetes ObservabilityGPU、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 SetsJenkins 同样支持基于 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 OSGPU 在 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 AllocationDRA已经在 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 网络栈并可以结合 DPDKVPP 官方也提供了 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 capacitykubeadm 的 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 的网卡。然后一个新的问题又会把我们带到新的地方。十三篇系列完。实验室不完。