离线内网部署大模型集群时,应部署coredns作为私有dns服务实现短域名互访;需配置file插件加载本地zone文件、forward插件处理上游请求,并统一客户端dns地址与search domain,配合自动化脚本维护节点映射,最后通过nslookup和ping验证解析与连通性。

离线内网部署大模型集群时,几十个节点间要实现 api、train01、storage 这类短域名互访(无需写完整域名如 train01.cluster.local),核心不是配 hosts 或改每个节点的 /etc/hosts,而是部署一个轻量、可集中管理、支持搜索域和条件转发的私有 DNS 服务,并让所有节点统一指向它。
选型与部署:用 CoreDNS 搭建内网 DNS 服务器
推荐使用 CoreDNS —— 它体积小、配置简洁、原生支持 search domain 和 forward 插件,且无需依赖外部网络即可运行:
- 在一台稳定节点(如管理节点或专用 DNS 节点)上用 Docker 启动 CoreDNS 容器,监听宿主机 53 端口(UDP/TCP)
- 挂载自定义 Corefile,关键配置包含两部分:
– 对.local或.ai等内网域名后缀,用file插件从本地 hosts 文件加载解析
– 对其他请求(如访问镜像仓库 registry.internal),启用forward插件指向上游(若内网有镜像 DNS 可填其 IP;否则可留空或配 fallback) - 确保防火墙放行 53/udp 和 53/tcp,宿主机绑定
0.0.0.0:53(非仅 127.0.0.1)
统一客户端配置:让所有节点自动识别短域名
节点不靠手动改 resolv.conf,而是通过标准化方式接入 DNS 服务:
将小说章节转换为电影分镜剧本。用户上传txt/md/docx文本,AI分析场景、角色、情绪、镜头语言,输出专业分镜脚本。适用于用户提及“分镜”“storyboard”“小说转分镜”“影视改编”“镜头脚本”或需要将小说改编为分镜的场景。
- 若用 systemd-networkd 或 NetworkManager,统一配置
dns=192.168.10.100(你的 CoreDNS 地址)和domains=ai local(即 DNS search domains) - 若用 DHCP 分发,可在 DHCP server 中注入 DNS 服务器地址 + search list(如
option domain-search "ai", "local") - 容器场景下,在 docker daemon.json 中设
"dns": ["192.168.10.100"], "dns-search": ["ai", "local"];Kubernetes 集群则通过 kubelet 的--cluster-dns和--cluster-domain统一指定
域名规划与维护:短名映射到节点 IP 的自动化闭环
几十个节点的 hostname 到 IP 映射不能靠人工维护,需结构化管理:
- 准备一份
nodes.csv或 YAML 清单,记录每台机器 hostname、IP、角色(如 master/gpu-worker/storage) - 用脚本(Python/Shell)自动生成 CoreDNS 的 zone file(如
/etc/coredns/local.db),内容格式为:train01 IN A 192.168.10.11storage IN A 192.168.10.20api IN A 192.168.10.5 - Corefile 中引用该文件:
local.ai:53 { file /etc/coredns/local.db local.ai },每次更新清单后 reload CoreDNS 即生效
验证与兜底:确保短域名真正可用
完成配置后,任一节点执行以下命令验证是否符合预期:
-
cat /etc/resolv.conf→ 确认 nameserver 是你的 CoreDNS IP,且 search 行含ai local -
nslookup train01→ 应返回对应 IP(不带后缀也能命中) -
nslookup api.storage→ 应能解析二级短名(因 search domain 自动补全) -
ping -c1 storage或curl http://api:8000/health→ 实际网络连通性测试 - 若失败,优先查 CoreDNS 日志:
docker logs coredns,看是否有 NXDOMAIN 或超时,确认是否收到查询、是否匹配了 file 插件










