Kubernetes中Job无法连接Cassandra Pod的域名解析问题排查

根据你描述的情况，手动执行命令正常但自动化Job抛出DNS解析错误，结合你提供的Job配置和resolv.conf信息，我整理了几个核心排查方向和解决方案：

1. ndots:5配置干扰域名解析 #

你的resolv.conf里设置了options ndots:5，这个规则会让系统对点数量少于5个的域名优先尝试用search域补全。而你使用的cassandra.my-namespace.svc.cluster.local只有4个点，系统会先去解析cassandra.my-namespace.svc.cluster.local.default.svc.cluster.local这类错误域名，直接导致解析失败。

解决方案： #

给域名加上末尾的点，强制解析完整的完全限定域名（FQDN），避免触发search域补全：

/bin/sh -c "cqlsh cassandra.my-namespace.svc.cluster.local. -f /path/to/schema.cql"

2. Job未部署到Cassandra所在Namespace #

你的Job配置中没有指定namespace字段，如果Helm Release默认部署在default Namespace，Job会自动跑在default下，而Cassandra在my-namespace。虽然跨Namespace用全域名理论上能解析，但结合ndots:5的设置，会大幅增加解析失败的概率。

解决方案： #

在Job的metadata中明确指定Namespace，确保和Cassandra同属一个命名空间：

apiVersion: batch/v1
kind: Job
metadata:
  name: init-db
  namespace: my-namespace  # 添加这一行指定命名空间
spec:
  template:
    metadata:
      name: init-db
      annotations:
        "helm.sh/hooks": post-install
    # 其余配置保持不变

如果Job和Cassandra在同一Namespace，你甚至可以简化命令为cqlsh cassandra -f /path/to/schema.cql，直接用Service名就能解析。

3. Helm Hook执行时机过早（次要排查点） #

post-install Hook会在Release标记为安装完成后立即执行，此时Cassandra StatefulSet的Pod可能还未完全就绪——不过你的错误是DNS解析失败而非连接超时，这个可能性较低。如果需要确保Cassandra服务就绪后再执行Job，可以给Hook添加权重或增加等待逻辑：

annotations:
  "helm.sh/hooks": post-install
  "helm.sh/hook-weight": "10"  # 让这个Hook晚于其他初始化Hook执行

或者添加initContainer等待Cassandra就绪：

spec:
  template:
    spec:
      initContainers:
      - name: wait-for-cassandra
        image: <cassandra-image>
        command: ["/bin/sh", "-c"]
        args:
        - |
          until cqlsh cassandra.my-namespace.svc.cluster.local. -e "describe keyspaces"; do
            echo "Waiting for Cassandra to be ready..."
            sleep 5
          done
      containers:
      # 你的cqlsh容器配置不变

验证方法 #

修改配置后重新安装Helm Chart，查看Job Pod的日志。如果问题依旧，可以进入Job的Pod执行以下命令对比解析结果：

nslookup cassandra.my-namespace.svc.cluster.local
nslookup cassandra.my-namespace.svc.cluster.local.

通过对比就能明确是否是ndots:5导致的解析异常。

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