上一篇【第89篇】K8s + AI/ML——在K8s上运行机器学习工作负载
系列完结，感谢阅读

---

摘要

从第一篇"K8s凭什么称霸容器编排"到这一篇，我们走完了90篇文章、从入门到精通的完整旅程。最后这篇不补技术细节，而是抬起头看看方向。

K8s今天已是云原生的操作系统，但它自己也在被重塑：Serverless想让开发者彻底忘记节点、WASM想用比容器更轻的沙箱替代运行时、eBPF想在内核里把网络和安全重做一遍、AI原生让K8s成了GPU和大模型的事实底座。这篇把四个趋势讲清，并给你一张继续往下走的学习地图。感谢一路跟到现在。

---

一、回望：K8s已经赢了，但"重"是事实

先承认一个现实。K8s很强，但也重：

【K8s 的"重"】

  - 一个Pod里至少塞个Pause容器, 还要跑kube-proxy/CSI/CNI
  - 起一个最简单的服务, 概念链: Pod→Deployment→Service→Ingress
  - 控制平面组件一堆, 小团队养不起
  - 冷启动慢(秒级到分钟级)

  用户真实心声: "我就想跑段代码, 凭啥要我先懂Scheduler?"

这正是Serverless和WASM想解决的根本矛盾——开发者不想管理基础设施，只想跑代码。K8s的下一步，就是让自己"隐形"。

---

二、Serverless：让K8s隐形

Serverless不是"没有服务器"，是"你不用管服务器"。在K8s世界里，代表是Knative：

【Knative 两层】

  Knative Serving  → 把应用变成"按需运行的服务"
     - 没流量时缩到 0 个Pod(省钱!)
     - 来流量自动扩容, 冷启动拉起
     - 流量按版本切(蓝绿/金丝雀原生支持)

  Knative Eventing → 事件驱动
     - 消息队列/K8s事件/定时 → 触发服务

  开发者只写:
     apiVersion: serving.knative.dev/v1
     kind: Service
     spec:
       template:
         spec:
           containers:
             - image: registry.example.com/myapp
  # 不用写Deployment/Service/Ingress, Knative自动生成

你提交的还是"一个应用"，Knative在背后自动生成K8s的Deployment/Service/Ingress，并接管伸缩（含缩容到0）。对开发者来说，K8s概念基本消失了。

要点：Serverless在K8s上的本质 = 自动伸缩 + 缩容到0 + 流量治理，把"运维复杂度"从用户肩上卸下来。Knative、以及云厂商的ASK/Cloud Run on GKE都是这个思路。

---

三、WASM：比容器更轻的"下一件大事"

WebAssembly（WASM）原本是浏览器里的沙箱，现在被搬到了服务端——WASM可以跑在服务器上，作为容器的替代运行时。

【容器 vs WASM】

  容器(OCI):
     镜像几十~几百MB
     启动百毫秒~秒级
     共享宿主机内核(隔离靠namespace/cgroup)
     需要完整libc/基础镜像

  WASM(WASI):
     模块几KB~几MB
     启动微秒~毫秒级
     沙箱隔离(默认不能碰系统, 安全)
     一次编译, 到处运行(真·跨平台)

WASM的优势太诱人：启动比容器快几个数量级、体积小数十倍、安全沙箱更干净。在K8s里，它通过 runtimeClass + WASM运行时（如WasmEdge/Spin） 接入，作为一个新的容器运行时：

apiVersion: v1
kind: Pod
spec:
  runtimeClassName: wasmedge          # 指定WASM运行时
  containers:
    - name: app
      image: registry.example.com/app.wasm   # 是wasm模块不是OCI镜像

适合什么？边缘计算、函数计算、冷启动敏感的场景。但WASM现在生态还早：很多库不支持WASI、不能跑有状态重服务。短期是容器的补充，不是替代。

要点：别被"WASM取代容器"的标题党带偏。现实是容器和WASM长期共存——重服务、有状态用容器，轻函数、边缘、极高密度用WASM。K8s的价值恰恰在于它能同时调度两者（通过runtimeClass）。

---

四、eBPF：在内核里重写K8s的数据面

eBPF我们在第049篇（Cilium）详细讲过，这里看它的"颠覆性"全局意义。传统K8s的网络、安全、可观测性都靠用户态的agent + iptables规则 + 旁路采集，而eBPF直接把逻辑塞进Linux内核：

【eBPF 重塑的三块】

  网络:
     kube-proxy 的 iptables/IPVS 规则
       → 被 Cilium(eBPF) 直接替代(Pod直连, 无规则链)
     网络策略 L3/L4 → L7(HTTP/gRPC/Kafka) 策略

  安全:
     在内核拦截系统调用(seccomp式)
     零信任网络策略无需sidecar

  可观测性:
     内核级追踪(socket/文件/系统调用)
     Hubble 直接看到每个连接的来龙去脉

eBPF的厉害在于不改应用、不改内核源码，就能在内核里插逻辑。这让K8s的网络从"一堆iptables规则"变成"内核里的智能转发"，性能更高、可观测性更强、还少了一层sidecar开销。

要点：eBPF是近年来K8s底层最大的技术变量。它让"网络/安全/观测"从用户态旁路下沉到内核态，Cilium是先锋。可以理解成：kube-proxy会被eBPF干掉，就像Docker被containerd干掉一样（第005篇）。

---

五、AI原生：K8s成了GPU的操作系统

第089篇我们已经深入讲了K8s跑AI。从"未来"视角看，这是K8s地位的一次跃迁：

【AI 原生 K8s】

  过去: K8s 调度 CPU/内存, 跑无状态Web服务
  现在: K8s 调度 GPU/TPU/NPU, 跑训练/推理

  新课题:
     - GPU 虚拟化(MIG/切分) → 资源利用率
     - 拓扑感知调度(NVLINK/跨节点) → 训练速度
     - 大模型推理的显存编排 → 一卡多模/多卡一模
     - 批处理调度(Volcano) → 排队公平, 不像在线服务逐Pod调度

  Volcano / Kueue 这类"批调度器"补上K8s原生缺的:
     "一组Pod要一起调度, 否则全不放"(gang scheduling)

K8s正在从"Web服务的编排器"变成"一切算力的调度中枢"——CPU、GPU、甚至TPU/NPU。AI浪潮非但没绕开K8s，反而把它推到了更中心的位置。

---

六、四个趋势一张图

趋势	解决什么	代表项目	成熟度
Serverless	开发者不想管节点	Knative / 云函数	生产可用
WASM	容器太重太慢	WasmEdge / Spin	早期, 边缘/函数为主
eBPF	内核态重塑网络/安全	Cilium / Hubble	快速普及中
AI原生	GPU/大模型调度	Kubeflow / Volcano / Kueue	高速演进

【K8s 的未来拼图】

   ┌──────────────────────────────────┐
   │          K8s 控制平面(稳定)        │
   │  API Server / etcd / Scheduler     │
   └──────────────────────────────────┘
      │           │            │
   运行时      数据面        工作负载
   ┌──┐        ┌──┐        ┌──────┐
   │容器│  +   │eBPF│  +   │Serverless│
   │WASM│      │Cilium     │AI训练  │
   └──┘        └──┘        └──────┘

   控制平面稳如磐石, 周边在剧烈进化

要点：注意一个规律——K8s的控制平面（API Server/etcd/Scheduler）越来越稳，而"周边"在剧烈进化：运行时多了一个WASM、数据面被eBPF重写、工作负载从Web扩展到AI和函数。核心不动，外延狂奔。

---

七、给你的学习地图（90篇之后怎么走）

走完90篇，你已经从"知道K8s"到了"能上手、能排障、能设计"。再往下：

【进阶路线】

  打深原理:
     - 读 kubernetes 源码(第060-072篇打的底)
     - 写一个自己的 Controller / Operator(第074篇)
     - 读懂 CNI/CSI 插件源码

  横向拓展:
     - 服务网格深入(Istio/Linkerd, 第077篇)
     - 可观测性三件套落地(Prometheus/Loki/Tempo)
     - GitOps 流水线(ArgoCD, 第078篇)

  跟上前沿:
     - eBPF/Cilium 实战
     - WASM 运行时试水
     - AI 平台(Kubeflow/Volcano)

  考证/社区:
     - CKA / CKAD / CKS
     - KubeCon 视频(每年两次, 趋势风向标)

要点：技术更新快，但控制平面的核心思想（声明式、控制器循环、调和）十年不变。把第060-072篇的原理吃透，你就能以不变应万变地理解所有新项目——它们只是换了外壳的Controller和CRD。

---

本篇小结（也是全系列结语）

90篇走到这里，我们从"K8s凭什么称霸容器编排"出发，遍历了容器基础、核心资源、调度存储网络、安全、核心原理、生态扩展、运维实战，最后落到实战案例与前沿。K8s的明天由四股力量重塑：Serverless（Knative让K8s隐形）、WASM（比容器更轻的沙箱，长期共存）、eBPF（在内核里把网络/安全/观测重做一遍，Cilium是先锋）、AI原生（K8s成为GPU和大模型的事实底座）。

记住那条规律：核心控制平面稳如磐石，周边剧烈进化。把声明式与控制器循环的思想学透，你就能看懂未来所有新项目——它们不过是换了外壳的CRD与Controller。感谢你一路跟到这里，去把K8s用起来吧，光看不练等于没学。

---

上一篇【第89篇】K8s + AI/ML——在K8s上运行机器学习工作负载
系列完结，感谢阅读

---