KubeCon North America 2025 Review

KubeCon North America 2025 13号结束了，官网上也有了些会议资料。挑了几个感兴趣的话题总结下。

Dynamic Routing with Multi-Cluster Inference Gateway#

https://kccncna2025.sched.com/event/27FeP/ai-inference-without-boundaries-dynamic-routing-with-multi-cluster-inference-gateway-rob-scott-google-daneyon-hansen-soloio?iframe=no&w=100%&sidebar=yes&bg=no

这段时间正好在做 AI 网关，这个话题可以说是“瞌睡了送枕头”。

推理服务和传统 API 流量相比，在 payload，响应时间，后端资源开销上都有着很大的差异（见下图）。

因此，推理网关需要做到后端负载感知的调度（传统 API 网关也有类似的方案，尤其是在后端机型不一样，普通的 rr 无法均匀负载时，做后端负载感知动态调权）。在 Gateway 和推理实例间引入了一个 EPP（Endpoint Picker）组件（注：EPP 现在也是 Kubernetes 做推理服务的一个通用组件），采集推理实例的指标来动态选择推理后端。

benchmark 数据显示，使用推理网关相比传统负载均衡，推理实例间的负载更加均衡，请求排队更少，从而降低了响应时间。

在多集群场景下，这套方案需要解决 3 个问题：

1. 服务发现：Cluster Inference Services 如何暴露给 Gateway？
2. 后端选择：Gateway 如何在多集群间分配流量？
3. 路由模式：流量如何从 Gateway 转发到集群？

第一个问题作者提了 3 个解决方法：

不是关注重点，略过。

第二个问题，简单的 RR 和 Active-Passive 肯定就失去了推理网关负载感知的优势。所以，在 EPP 感知负载之外，Gateway 也得做负载感知。作者也提了两个方法：

从层级上来说，EPP Aggregate Metrics 方案更加简洁，毕竟在 EPP 上还得做二次调度。

最后一个问题，如果 EPP 能跨集群直接访问，direct routing 是最合适的方式，不行的话再加一层网关，使用 Cluster-Local Gateway 做暴露也能访问。

总结一下，这篇演讲的主要思路是利用负载感知在提高推理网关服务的性能。提出了多种方式解决单集群服务迁移到多集群服务时面临的问题。但是也要注意到，系统的整体复杂性也有一个提升。如何保证系统的稳定性以及多层感知的准确性，也是在实际工程实践中需要注意的地方。

Routing Stateful AI Workloads in Kubernetes#

https://kccncna2025.sched.com/event/27FX6/routing-stateful-ai-workloads-in-kubernetes-maroon-ayoub-ibm-michey-mehta-red-hat?iframe=no&w=100%&sidebar=yes&bg=no

这篇演讲也是讲推理服务的流量调度的，介绍了 llm-d。核心要点有 3 个：

1. AI Workloads Are Stateful
2. K8s Networking is blind to AI
3. llm-d makes Kubernetes AI-Aware

和上篇关注于负载不同，这篇演讲主要关注于 KVCache 对于推理服务流量调度的影响。Prefix Caching 能利用缓存跳过 expensive prefill，提高总体吞吐，降低 TTFT。

所以，推理服务实质上是有状态服务。

“The KV-cache hit rate is the single most important metric for a production-stage AI agent. It directly affects both latency and cost.”

• Manus, Context Engineering for AI Agents

• OpenAI GPT-5: $1.25 per 1M input tokens vs $0.125 per 1M cached input tokens
• Anthropic Claude Sonnet: $3 per 1M input tokens vs $0.3 per 1M cached input tokens

而传统的 Kubernetes 流量调度（Round-Robin，Load-Aware）都无法做到 Prefix-Cache Aware Scheduling，自然无法保证 cache hit rate。

多轮对话场景下 precise prefix cache-aware scheduler 和 load-aware scheduler 性能对比：

llm-d precise prefix cache-aware 实现方式：

对于每一个请求：

1. Query the kvcache.Index
2. Calculate prefix-cache affinity score per pod:
   1. % of prefix already cached
   2. Represents saved computational work
3. Combine with load-aware scores:
   1. vLLM queue depth
   2. KV-cache utilization
   3. Others
4. Route to maximize cache hits while balancing load

在保证不制造热点的情况下达到最高的 cache 亲和性。

llm-d 仓库中的架构图如下：

https://github.com/llm-d/llm-d-inference-scheduler/blob/v0.3.2/docs/architecture.md

Scaling and Securing CoreDNS: Performance and Resilience#

https://kccncna2025.sched.com/event/27Nn5/scaling-and-securing-coredns-performance-and-resilience-yong-tang-datadirect-networks-john-belamaric-google?iframe=no&w=100%&sidebar=yes&bg=no

介绍了 CoreDNS 1.12.0 - 1.13.1 版本的一些新特性。主要有：

multisocket plugin

核心是利用 reuseport 提高 CoreDNS 单实例在多核扩展时的性能。


社区在2022年的 issue 就开始了关于 CoreDNS 在多核时性能不佳的讨论：https://github.com/coredns/coredns/issues/5595 。不过容器化的好处是可以用小规格启动更多的实例（HPA）来规避这个问题。

kubernetes plugin multicluster support

multicluster defines the multicluster zones as defined by Multi-Cluster Services API (MCS-API). Specifying this option is generally paired with the installation of an MCS-API implementation and the ServiceImport and ServiceExport CRDs. The plugin MUST be authoritative for the zones listed here.

Every Kubernetes Pod Eviction Path Explained#

https://kccncna2025.sched.com/event/27Fdd/evicted-all-the-ways-kubernetes-kills-your-pods-and-how-to-avoid-them-ahmet-alp-balkan-linkedin?iframe=no&w=100%&sidebar=yes&bg=no

总结一张图：

关于PDB：

Kubernetes Pod Disruption Budget (PDB) 是一种 Kubernetes API 对象，它的主要作用是在集群执行自愿性中断操作时，确保特定应用程序始终有一定数量的 Pod 在运行，从而避免应用程序的服务中断或性能下降。

简单来说，PDB 就是给你的应用设定一个“预算”，这个预算规定了在任何时候，最多有多少个 Pod 可以同时因为自愿性中断而下线，或者说最少有多少个 Pod 必须保持运行。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 70% # 至少70%的Pod必须保持运行
  selector:
    matchLabels:
      app: my-app

Designing for observability: From noise to insight#

https://kccncna2025.sched.com/event/27Fbk/designing-for-observability-from-noise-to-insight-andrea-chomiak-dash0?iframe=no&w=100%&sidebar=yes&bg=no

总结一张图：

Benchmarking GenAI Foundation Model Inference Optimizations on Kubernetes#

https://kccncna2025.sched.com/event/27FVD/benchmarking-genai-foundation-model-inference-optimizations-on-kubernetes-sachin-mathew-varghese-capital-one-brendan-slabe-google?iframe=no&w=100%&sidebar=yes&bg=no

kubernetes-sig 下的新项目：https://github.com/kubernetes-sigs/inference-perf，用来对推理服务做 benchmark。

inference-perf 具备以下关键能力：

• 高可扩展性：能处理大规模测试。
• 灵活的负载模拟：能模拟各种真实和极限的流量模式。
• 智能的提示生成：能生成真实世界和合成的、特定用例的测试数据。
• 精细的控制能力：能精确控制输入输出的长度和分布，以及系统提示，从而进行高度定制化和科学的性能评估。

目标是帮助开发者和运维团队全面理解他们的LLM部署在各种真实和压力场景下的表现，发现瓶颈，优化性能，并确保稳定性。

演讲中建立了大模型的时延-吞吐量的性能模型：

• Latency Throughput Curve: Describes performance under loads that do and do not saturate the serving stack/cause request queuing.

但是感觉图中的 x y 轴弄反了，output tokens 作为负载应该放在 x 轴，TTFT，TPOT 和 Inter-token latency 作为指标应该放在 y 轴。

QEMU in the Fast Lane: Accelerating KubeVirt Networking with eBPF#

https://kccncna2025.sched.com/event/27FXg/qemu-in-the-fast-lane-accelerating-kubevirt-networking-with-ebpf-daniel-borkmann-anton-protopopov-isovalent-at-cisco?iframe=no&w=100%&sidebar=yes&bg=no

Daniel 大佬的演讲，这次将 cilium 扩展到虚拟化的领域中。

现有的 Kubevirt 网络是由 veth pair（host ns to pod ns）+ bridge + tap（pod ns to vm）两部分组成的。

cilium 的 netkit driver 已经在容器网络中对第一部分进行了优化，完全消除了 netns 带来的 overhead。

性能对比，netkit + BPF host routing 已经和 host 网络持平：

在 kubevirt 网络中应用 netkit 也带来了 13% 左右的吞吐提升：

但是第二部分 bridge + vtap 仍然有优化的空间。

一种思路是利用 SR-IOV，物理网卡直通虚拟机。但是存在的问题是：

• 直通后，虚拟机网络对宿主机完全隐藏，没法做可观测和网络策略
• 能力依赖于底层硬件的支持

另外一种思路是利用 AF_XDP。

但是，pod netns 内是没有 AF_XDP 支持的。没有怎么办？那就改代码让它支持咯。

利用网卡的 RSS 和多队列，netkit 上也创建多个 rx queues 和 网卡队列做绑定，实现容器 netns 内的数据直通：

该方案完成的话，未来的 cilium + kubevirt 网络栈：

性能对比：