上一篇【第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比容器更轻的下一件大事WebAssemblyWASM原本是浏览器里的沙箱现在被搬到了服务端——WASM可以跑在服务器上作为容器的替代运行时。【容器 vs WASM】 容器(OCI): 镜像几十~几百MB 启动百毫秒~秒级 共享宿主机内核(隔离靠namespace/cgroup) 需要完整libc/基础镜像 WASM(WASI): 模块几KB~几MB 启动微秒~毫秒级 沙箱隔离(默认不能碰系统, 安全) 一次编译, 到处运行(真·跨平台)WASM的优势太诱人启动比容器快几个数量级、体积小数十倍、安全沙箱更干净。在K8s里它通过runtimeClass WASM运行时如WasmEdge/Spin接入作为一个新的容器运行时apiVersion:v1kind:Podspec:runtimeClassName:wasmedge# 指定WASM运行时containers:-name:appimage: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的明天由四股力量重塑ServerlessKnative让K8s隐形、WASM比容器更轻的沙箱长期共存、eBPF在内核里把网络/安全/观测重做一遍Cilium是先锋、AI原生K8s成为GPU和大模型的事实底座。记住那条规律核心控制平面稳如磐石周边剧烈进化。把声明式与控制器循环的思想学透你就能看懂未来所有新项目——它们不过是换了外壳的CRD与Controller。感谢你一路跟到这里去把K8s用起来吧光看不练等于没学。上一篇【第89篇】K8s AI/ML——在K8s上运行机器学习工作负载系列完结感谢阅读