Multus-CNI中Pod网络配置导致Kubernetes内部DNS解析失败的解决方案

在Kubernetes网络插件Multus-CNI的实际应用中，用户经常遇到为Pod配置额外网络接口后导致Kubernetes内部DNS服务不可用的问题。本文将从技术原理层面分析这一现象的成因，并提供有效的解决方案。

问题现象分析

当用户通过Multus-CNI为Pod添加macvlan类型的第二网络接口时，如果网络配置中包含默认路由的设置，Pod将失去与Kubernetes内部DNS服务的连接能力。这主要表现为：

• 无法解析集群内部服务名称（如kubernetes.default.svc.cluster.local）
• 无法访问集群内部服务

根本原因

问题的核心在于网络路由表的变更。在示例配置中：

{
  "routes": [ { "dst": "0.0.0.0/0" } ],
  "gateway": "193.169.1.1"
}

这段配置会导致Pod的默认路由被修改为指向macvlan网络的网关，而非原有的Kubernetes集群网络。这会产生两个关键影响：

1. DNS查询请求被路由到外部网络而非集群内部的CoreDNS服务
2. Pod与Kubernetes API服务器及其他集群服务的通信路径被破坏

解决方案

方案一：移除默认路由配置

最直接的解决方案是修改NetworkAttachmentDefinition配置，移除默认路由设置：

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan
spec:
  config: >-
    {
      "cniVersion": "0.3.1",
      "name": "macvlan",
      "type": "macvlan",
      "mode": "bridge",
      "master": "ens18",
      "ipam": {
        "type": "host-local",
        "subnet": "193.169.1.0/24",
        "rangeStart": "193.169.1.100",
        "rangeEnd": "193.169.1.150"
      }
    }

方案二：保留特定路由

如果需要同时访问集群内外网络，可以配置更精确的路由规则：

{
  "routes": [
    { "dst": "193.169.1.0/24" },
    { "dst": "10.96.0.0/12" }  # 假设这是集群的Service CIDR
  ]
}

验证方法

部署后可通过以下命令验证网络配置：

# 查看Pod的路由表
kubectl exec <pod-name> -- ip route

# 测试DNS解析
kubectl exec <pod-name> -- nslookup kubernetes.default

最佳实践建议

1. 尽量避免在附加网络配置中覆盖默认路由
2. 如需多网络接入，考虑使用策略路由（policy routing）
3. 对于关键业务Pod，建议先测试网络连通性再投入生产
4. 记录集群的Service CIDR和Pod CIDR，便于配置精确路由

通过合理配置Multus-CNI网络附件，可以确保Pod在获得额外网络能力的同时，保持与Kubernetes集群内部服务的正常通信。理解底层网络原理有助于快速定位和解决此类网络连通性问题。