本文介绍KubeCon NA 2026（盐湖城）面向最终用户的内容：BoF环节聚焦平台工程、公共部门、电信、科研等用户组，并尝试现场构建Agentic AI参考架构；另设用户咨询台和海报交流。CNCF最终用户TAB成员推荐多场演讲，涵盖Kubernetes集群扩展与多集群管理、ML负载导致调度器故障、GovCloud合规、CNI零停机迁移、GPU可观测性与调度、eBPF网络成本归因及AI代理沙箱等实践。

Kubernetes 虽有 CRD、控制器、CEL 等组件，却缺少“编排配方”，即没有机制说明多个资源如何组成一体、字段依赖如何排序，导致 Helm、Argo CD、Crossplane 等各自重复实现同一套组合逻辑。kro 项目提出 ResourceGraphDefinition，用 CEL 引用自动推导依赖顺序，以数据形式描述资源连接，一个控制器即可解释所有定义；其 Graph 功能可仅做组合而无需创建 API。文章认为，组合可能是 Kubernetes 缺失的基础原语。

在Kubernetes上运行AI代理生成的代码存在安全风险：代理会执行未经人工审查的代码，可能利用内核漏洞危及共享节点，因此工作负载隔离成为平台的基本需求。文章比较了runc、gVisor和Kata Containers三种运行时在安全与性能之间的权衡，介绍了通过RuntimeClass让代理Pod选用隔离运行时，并提及Agent Sandbox项目可标准化有状态的单Pod环境，支持模板、声明和预热池。

KServe是CNCF孵化项目，用于解决AI团队模型上线后的服务管理问题。它不负责GPU推理（由vLLM等引擎承担），而是管理版本、流量切分、扩缩容和回滚。核心抽象InferenceService让模型成为K8s一等公民，并复用GitOps流程。针对大模型，KServe推出LLMInferenceService专用CRD，默认绑定vLLM，集成llm-d分布式调度和Envoy AI Gateway流量治理。但模型较少时不必引入，因其运维复杂度高，且LLMInferenceService仍为alpha版。

本文讨论Kubernetes大规模集群控制平面的可用性风险：组件即使不崩溃，也可能通过共享元数据、同步启动或过度健康检查放大局部故障。文中分析三个案例：扩展API发布无效的OpenAPI v2模式，导致无关Helm部署失败；DaemonSet代理同时重启引发API请求风暴；存活探针将KMS依赖故障误判为进程故障，导致反复重启。建议验证实际模式、限制informer范围、区分依赖检查与能力检查。

本文介绍 EKS Fargate 实现无服务器 Kubernetes 的方式：通过准入 Webhook 将符合 Fargate 配置的 Pod 路由至专用调度器，按需创建独立计算环境，而非从节点池中选择。运行时提供 Kubelet 等节点组件，并利用网络命名空间隔离平台、节点与工作负载流量，每个 Pod 获得独立 ENI。EKS 还通过 PodAdmitHandler 限制单 Pod 单环境，并定期以 Eviction API 优雅替换 Pod 以完成打补丁。

《Kubernetes in 2027》电子书指出，AI与智能体工作负载为Kubernetes平台带来新挑战，团队不能只关注Pod运行或GPU利用率。部署前需压测模型服务并演练故障；对智能体访问集群应明确负责人、最小权限、审批与审计；同时兼顾跨集群策略、外部服务可观测性、升级恢复演练及成本归属等平台工作。

KubeVirt正从在Kubernetes上运行虚拟机，发展为更广泛的虚拟化生态。未来重点包括：用DRA统一分配GPU、网卡和CPU；支持机密虚拟机与远程证明；通过插件机制扩展核心功能；让虚拟化栈可插拔，以支持Cloud Hypervisor、Firecracker等替代方案。项目坚持Kubernetes原生和核心稳定原则，并推动成为CNCF毕业项目。

AI代理能在Kubernetes上自主推理并调用工具，打破了K8s假设软件仅按指令运行的模型，带来安全与运维挑战。CNCF调查显示，三分之二的组织已在K8s上运行AI推理。应对方式包括沙箱隔离、明确权限框架和监控代理行为。代理生命周期短暂、需快速启动，催生了“热池”式代理基座，可实现毫秒级恢复。商业K8s发行版已提供这些能力。

文章指出Kubernetes自动扩缩存在架构缺陷：HPA、VPA、KEDA、Karpenter等控制器各自独立运行，基于局部信息做出相互矛盾的决策，导致扩缩震荡、GitOps冲突和资源浪费。根本原因是工作负载容量本是一个耦合的优化问题，却被拆分成多个解耦控制器。解决方案是保留各执行组件，但增加统一智能控制层，综合副本、资源请求与成本，实现真正的自主决策。

该工作坊在 ContainerDays 2026 新加坡站介绍 CNCF 孵化项目 HAMi 的 GPU 共享方案：借助 kind 集群与模拟设备插件伪造两块 A100-40GB 显卡，无需真实 GPU 即可观察调度过程。内容涵盖 GPU 共享动机（避免大卡被小任务独占）、HAMi 架构（webhook、调度器扩展、设备插件等）以及按显存和算力申请切片；四个实验分别覆盖安装、GPU 共享与拦截链、binpack 与 spread 调度策略、KAI Scheduler 与 Volcano vGPU 等扩展路径，最后介绍指标与 WebUI。

本文是KubeCon前瞻专栏，聚焦Kubernetes应对AI代理负载的挑战：HPE推出Pod重启自动诊断工具；AWS指出调度器与自动扩缩器需协同以避免GPU闲置；llm-d发布v1.0降低推理成本；CNCF称AI代理流量已超人类；研究显示为编码代理提供上下文可更快诊断集群故障；Valkey指出指标缺失并非时序状态；Splunk调查显示多数企业难以监控AI质量与成本。

本文介绍如何用Kamaji与HAMi在单机无GPU环境下搭建多租户GPU共享平台。Kamaji将各租户的Kubernetes控制面以Pod形式运行在同一管理集群中，实现租户隔离；HAMi支持Pod按显存和算力比例申请GPU切片，使多个Pod共享一张显卡。作者通过模拟设备插件伪造A100和L4显卡，完成两个租户集群的部署，八项测试全部通过，验证了调度、超额申请拒绝和租户隔离。主要问题是模拟插件不释放节点锁，需手动添加注解解决。该实验仅验证调度链路，未测试真实GPU隔离与性能。

云原生应用常出现“幽灵卡顿”：Kubernetes探针和节点指标正常，用户却遭遇间歇性延迟，原因是基础探针无法反映完整请求性能。解决需持续采集跨层遥测数据，关联用户症状与历史信号，并借助AI辅助分析。外部依赖需用合成监测量化。AI可辅助排查，但变更操作仍须人工监督。

Kubernetes调度器与自动扩缩器长期独立分工，在AI加速器场景下导致Pod待调度而加速器闲置。社区通过动态资源分配（DRA）统一硬件描述语言，解决预留容量、拓扑亲和与设备共享问题；但组调度等仍需二者协同。目前SIG-Autoscaling正推动集成API，让扩缩器感知调度需求，避免重复模拟与资源浪费。

文章指出Kubernetes控制平面存在三类瓶颈：训练集群受节点数量限制，代理平台因对象频繁创建销毁而承受高写入压力，平台集群则因大量对象常驻内存而受限。作者提出四个“接缝”方案：分离存储、优化节点心跳、按哈希分片、控制缓存驻留，主张采用上游原生组件和经过规模测试的配置来解决，而非简单增加apiserver。

文章指出，AI代理与Kubernetes操作器不可互换：操作器按规则可预测地调谐状态，AI代理擅长在路径不明时调查、推理并提出方案。更安全的架构是代理负责推理与上下文，操作器、策略引擎等确定性系统保留执行控制权。以kagent为例，代理可自动执行只读操作，变更需审批，形成观察、诊断、提议、批准、调谐、验证的闭环。文章以Karpenter和Argo CD为例，说明代理应在其之上工作，输出有证据的窄范围补丁，经审批后由操作器执行并验证结果。团队应逐步引入，关键是每个动作都须被授权、有界、可观测且可回滚。

本期Road to KubeCon云原生动态：HPE Morpheus获SUSE认证并支持SLES 16；平台工程日11月9日举行，聚焦AI代理；CNCF沙箱项目kagent可将AI代理作为Kubernetes资源运行；有观点认为Kubernetes正成为AI操作系统，但并非所有场景都需要。