Kubeflow KFServing中InferenceGraph路由解析问题的分析与解决

问题背景

在使用Kubeflow KFServing的InferenceGraph功能时，发现了一个与DNS解析相关的有趣问题。当在一个双节点的MicroK8s集群上部署包含两个服务的推理图时，只有与CoreDNS Pod位于同一节点上的服务能够被成功访问，而另一个节点上的服务则出现连接超时。

环境配置

该环境使用了以下关键组件：

• MicroK8s 1.28.3集群（两个节点）
• KServe v0.11.2
• Istio 1.17.2
• Knative v1.10.1

集群中启用了CoreDNS，但仅有一个副本运行在其中一台节点上。

问题现象

当创建包含两个服务的InferenceGraph时：

1. transformer-a-model：部署在没有CoreDNS Pod的节点上
2. transformer-b-model：部署在有CoreDNS Pod的节点上

观察到的现象是：

• 只有transformer-b-model能够被成功访问
• transformer-a-model的请求会超时
• 检查transformer-a-model的日志，没有发现新的请求记录

根本原因分析

这个问题本质上是一个Kubernetes DNS解析的配置问题。在MicroK8s环境中，默认的CoreDNS配置可能没有正确处理跨节点的服务解析请求。具体表现为：

1. DNS解析请求被限制在本地节点
2. 当CoreDNS Pod不在请求发起节点时，解析请求无法正确路由
3. 服务发现机制在跨节点场景下失效

解决方案

通过调整CoreDNS的部署配置可以解决这个问题：

1. 确保CoreDNS以DaemonSet方式部署，每个节点都有CoreDNS实例
2. 或者增加CoreDNS副本数并确保它们分布在不同的节点上
3. 检查kubelet的DNS配置，确保所有节点都能正确转发DNS请求

在MicroK8s环境中，可以通过以下命令确保DNS服务的高可用性：

microk8s enable dns:default

最佳实践建议

对于生产环境中的KFServing部署，建议：

1. 始终确保DNS服务的高可用性
2. 对于关键业务组件，考虑使用DaemonSet部署模式
3. 定期测试跨节点服务发现功能
4. 监控DNS解析延迟和错误率
5. 考虑使用节点亲和性规则，确保关键服务与DNS服务协同定位

总结

这个案例展示了Kubernetes服务发现机制在实际部署中的潜在问题。通过理解CoreDNS的工作原理和Kubernetes的网络模型，我们能够快速诊断并解决这类跨节点服务解析问题。对于使用KFServing构建复杂推理管道的团队来说，确保基础DNS服务的可靠性和高可用性是保障系统稳定运行的关键因素之一。