Kubernetes集群中使用dnsmasq部署DHCP服务无法正常分配IP问题咨询

1. 修正测试用NAD配置（当前测试方法错误） #

你当前用于创建测试Pod的NAD配置了ipam.type=static，CNI会直接为Pod的eth2网卡绑定静态IP，根本不会发起DHCP请求，自然无法验证dnsmasq的DHCP功能。
需要单独创建用于DHCP客户端的NAD，IPAM类型改为dhcp：

cat <<EOF | kubectl create -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-dhcp-client
  namespace: dhcp
spec:
  config: '{
            "cniVersion": "0.3.0",
            "type": "macvlan",
            "master": "eth2",
            "mode": "bridge",
            "ipam": {
                "type": "dhcp"
            }
        }'
EOF

用这个NAD创建测试Pod，才会主动发起DHCP请求获取IP。

2. 检查节点网卡配置 #

• 节点上的eth2网卡需要开启混杂模式，才能接收目标MAC不是自身的广播报文：

  ip link set eth2 promisc on
  

  要永久生效可以修改网卡配置文件，避免重启后失效。
• 确认节点的iptables/ebtables规则没有丢弃UDP 67/68端口的DHCP广播报文。

3. 验证dnsmasq服务状态 #

进入dnsmasq Pod执行以下检查：

• 确认进程正常运行，参数正确：

  ps aux | grep dnsmasq
  

  注意检查启动参数中dhcp-range、监听网卡等配置和预期一致，避免Dockerfile的CMD参数和配置文件冲突。
• 确认服务正确监听DHCP端口：

  ss -ulnp | grep 67
  

  正常应该返回dnsmasq进程在0.0.0.0:67或者eth2的IP上监听UDP 67端口。
• 查看dnsmasq运行日志，你已经配置了log-dhcp参数，所有DHCP请求和响应都会打印在日志中：

  kubectl logs <你的dnsmasq Pod名称> -n dhcp
  

  如果日志中没有收到DHCP请求的记录，说明广播报文没有到达Pod。

4. 验证二层连通性 #

同时在节点的eth2和dnsmasq Pod的eth2上抓包，对比报文情况：

• 节点侧抓包：

  tcpdump -i eth2 udp port 67 or 68 -vv
  

• Pod侧抓包：

  kubectl exec -it <你的dnsmasq Pod名称> -n dhcp -- tcpdump -i eth2 udp port 67 or 68 -vv
  

如果节点能抓到DHCP请求报文，但Pod侧抓不到，说明是macvlan配置问题：

• 确认dnsmasq Pod和测试Pod用的是同一个master网卡（eth2）的macvlan配置
• 确认macvlan模式为bridge，同节点的macvlan子接口可以二层通信
• 如果客户端是节点外的物理机/虚拟机，确认和节点eth2在同一个二层广播域，没有三层设备隔离广播包。

其他注意事项 #

你当前dnsmasq配置中dhcp-boot=/var/lib/tftpboot/pxelinux.0配置有误，因为已经指定了tftp-root=/var/lib/tftpboot，dhcp-boot只需要填写相对路径pxelinux.0即可，否则PXE客户端会请求错误的文件路径。

内容的提问来源于stack exchange，提问作者rekarri