如何通过主机名获取节点内网IP？K8s部署HDFS节点扩展疑问

一、kube-dns/CoreDNS能否实现节点主机名解析？ #

默认情况下，kube-dns（现在集群普遍用CoreDNS作为默认DNS组件）并不负责解析Kubernetes节点的主机名到其内网IP——它的核心职责是处理集群内Pod、Service等资源的DNS记录。但通过自定义配置，CoreDNS确实可以实现这个功能，具体有两种实用方式：

• 启用CoreDNS的node插件：
  如果你的集群CoreDNS配置中还没启用node插件，添加后它会自动将节点的主机名解析为节点的InternalIP（内网IP）。你需要在CoreDNS的Corefile里补充类似配置：

  cluster.local {
      ...
      node /cluster.local/
      ...
  }
  

  同时，别忘了给DataNode Pod设置dnsPolicy: ClusterFirstWithHostNet——因为用了hostNetwork模式，Pod默认会用主机的DNS配置，这个策略能让Pod优先使用集群DNS服务。这样新增节点后，CoreDNS会自动感知节点的主机名和内网IP，现有节点的DataNode就能正常解析新节点的主机名了。

• 自定义hosts插件添加节点映射：
  要是不想启用node插件，也可以手动在CoreDNS的ConfigMap里添加节点主机名与内网IP的映射，比如：

  hosts {
      10.0.0.10 node-1.example.com
      10.0.0.11 node-2.example.com
      ...
      fallthrough
  }
  

  不过这种方式需要手动更新配置，不够自动化。你可以搭配一个简单的自定义脚本或Operator，监听Node资源的创建事件，自动同步新增节点的信息到CoreDNS的hosts配置里。

二、其他HDFS集群节点扩展方案 #

除了通过DNS解决解析问题，还有几种更贴合HDFS特性和Kubernetes编排逻辑的方案：

1. 修改HDFS配置，直接用IP通信 #

HDFS本身支持通过IP直接交互，你可以修改hdfs-site.xml里的两个关键配置：

<property>
    <name>dfs.datanode.use.datanode.hostname</name>
    <value>false</value>
</property>
<property>
    <name>dfs.namenode.datanode.registration.ip-hostname-check</name>
    <value>false</value>
</property>

这样DataNode向NameNode注册时会用自身的内网IP，现有节点也直接通过IP访问新节点，完全跳过主机名解析环节。这个方案最省心，但要确保节点的内网IP是稳定的（比如云服务器的固定内网IP、物理机的静态IP）。

2. 用StatefulSet + Headless Service部署DataNode #

如果不需要严格的「每个节点一个DataNode」，可以用StatefulSet部署DataNode，配合Headless Service为每个实例提供稳定的DNS记录（比如datanode-0.hdfs-datanodes.default.svc.cluster.local）。NameNode通过这个稳定域名和DataNode通信，新增实例时StatefulSet会自动创建对应的Pod和DNS记录，不用操心解析问题。

要是你坚持每个节点只跑一个DataNode，可以给StatefulSet加节点亲和性配置：

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - hdfs-datanode
      topologyKey: kubernetes.io/hostname

这样就能保证同一节点不会调度多个DataNode实例。

3. 同步节点主机名到所有节点的/etc/hosts #

用DaemonSet部署一个轻量级的同步服务（比如基于busybox的脚本），定期从Kubernetes API拉取所有节点的主机名和内网IP，然后更新每个节点的/etc/hosts文件。这种方式不依赖集群DNS，直接在主机层面解决解析问题，但要注意Pod需要有写入主机/etc/hosts的权限（比如把主机的/etc/hosts挂载到Pod里）。

总结 #

如果想继续用DaemonSet + hostNetwork的模式，优先考虑启用CoreDNS的node插件并配置正确的DNS策略，这是最自动化的DNS解决方案；如果不想依赖DNS，修改HDFS配置用IP通信是最直接的方式；StatefulSet方案则更贴合Kubernetes的原生编排特性，适合对DataNode实例有灵活管理需求的场景。

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