开启 hostNetwork 后 Service 名称解析失败：ClusterFirst 可能退回节点 DNS
普通 Pod 能解析 Service，hostNetwork Pod 却失败时，检查 ClusterFirst 是否退回节点 DNS。按 Linux 适用条件设置策略，并区分命名空间与 DNS 可达性。
同一个 Kubernetes Service，普通 Pod 能按名称访问，设置 hostNetwork: true 的 Pod 却解析失败。先检查失败 Pod 的 dnsPolicy 和 /etc/resolv.conf，不要立即重启 CoreDNS。
在 Linux Pod 中，hostNetwork: true 配合 ClusterFirst 会退回 Default 的行为，使用节点的 DNS 配置。需要让这类 Pod 使用集群 DNS 时，应明确设置 ClusterFirstWithHostNet。省略 dnsPolicy 默认采用 ClusterFirst，并不会自动选择带 HostNet 的策略。Windows Pod 不支持 ClusterFirstWithHostNet，不能直接套用这条处理路径。
对照失败 Pod 与普通 Pod 的 DNS 配置
先查看实际集群对象，而不是只看本地清单。以下是只读示例，命名空间和 Pod 名需要替换：
kubectl -n app get pod worker-hostnet -o yaml
kubectl -n app exec worker-hostnet -- cat /etc/resolv.conf
第二条要求镜像里有 cat。精简镜像没有该工具时，使用既有诊断方式查看解析配置，不要把命令不存在当作 DNS 故障。
重点比较 hostNetwork、dnsPolicy、nameserver 和 search 域。普通 Pod 指向集群 DNS，而失败 Pod 使用节点的公共或本地解析器，是策略回退的线索。节点 DNS 通常并不了解 Kubernetes 内部的 Service 名称；Pod 能解析公网域名，不能据此证明集群 DNS 已配置正确。
如果失败 Pod 已使用 ClusterFirstWithHostNet，并且解析器指向预期集群 DNS，就继续检查查询目标、到 DNS 服务的路径和 DNS 服务本身，不能重复修改同一个策略。
Service 的命名空间也要对上
短名称通常先按发起查询的 Pod 所在命名空间解析。目标 Service 位于另一个命名空间时，使用带命名空间的名称，例如 api.backend；需要完整名称时，可按实际集群域使用 api.backend.svc.cluster.local，不能假设所有集群都采用 cluster.local。
如果完整名称能解析、短名称失败，应核对 search 域和命名空间。若名称能解析到预期 Service 地址，但应用仍连接失败，应转查 Service 后端、端口和业务监听；那已经不是单纯的名称解析问题。
普通 Pod 与 hostNetwork Pod 的对照应尽量使用相同目标和实际查询条件。跨命名空间、不同节点或不同镜像的结果，都可能包含额外差异。
在受维护的 Pod 模板中设置策略
以下是 Deployment 或 DaemonSet 内的局部结构示例：
spec:
template:
spec:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
它假设工作负载本来就需要 hostNetwork，只补充与它匹配的 DNS 策略。不要为了 DNS 问题给普通 Pod 新增 hostNetwork；共享节点网络会改变端口占用和网络隔离条件。
将修改放入原 Helm、GitOps 或清单管理入口。更新 Pod 模板通常需要替换 Pod 才能生效，修改前保留原配置，核对副本、节点端口占用、就绪检查和允许的维护影响。不要仅改一份没有被部署使用的 YAML，也不要直接编辑受控制器管理的单个 Pod 来期待长期保留。
新 Pod 仍失败时，按实际解析路径继续查
确认新 Pod 已采用审定策略，再核对它看到的 nameserver。解析器已经正确却发生超时，应检查从该 Pod 或节点网络到 DNS 服务的访问；解析返回错误时，核对目标 Service 是否存在、DNS Pod 和对应 Service、EndpointSlice 是否正常。
hostNetwork 不会替你保证 DNS 服务地址可达。也不要因为有一个 Pod 查询失败，就全局修改节点 /etc/resolv.conf、把所有 Service 地址写进 hosts，或删除 CoreDNS 配置重建。
成功标准是替换后的目标 Pod 能用预期名称解析到正确 Service 地址，应用连接也正常，重新创建后仍保留同一策略。若部署异常，恢复原 Pod 模板并按管理流程回退；回退会重新替换 Pod，应同时确认原业务和节点端口状态。