1. 项目背景与问题定位

在Kubernetes集群中部署Nacos 3.1.1服务时，开发者经常会遇到java.net.UnknownHostException异常。这个看似简单的DNS解析问题，实际上涉及K8s服务发现机制、Nacos集群通信原理以及JVM网络配置等多个技术维度的交叉影响。我在最近的生产环境迁移项目中就遇到了这个经典问题，经过三天深度排查和多种方案验证，最终找到了稳定可靠的解决方案。

典型错误表现为Nacos节点启动后无法解析其他Pod的域名，日志中频繁出现类似java.net.UnknownHostException: nacos-cluster-service.default.svc.cluster.local的报错。这个问题会导致Nacos集群无法正常形成，进而影响所有依赖Nacos的服务发现功能。值得注意的是，该问题在Nacos 2.x版本中较少出现，但在3.x版本尤其是3.1.1版本中变得尤为突出。

2. 问题根源深度解析

2.1 K8s DNS解析机制与JVM的冲突

Kubernetes集群内部的DNS解析依赖CoreDNS服务，当Pod内的应用尝试解析<service-name>.<namespace>.svc.cluster.local格式的域名时，请求会先被Pod的/etc/resolv.conf中配置的nameserver接管。而JVM有一个特殊行为——默认会缓存DNS解析结果永久有效（默认缓存策略为FOREVER），这与K8s动态IP分配的特性直接冲突。

验证方法：

# 进入Nacos Pod执行 kubectl exec -it nacos-0 -- bash cat /etc/resolv.conf ping nacos-cluster-service.default.svc.cluster.local

2.2 Nacos 3.x集群通信的变化

相比2.x版本，Nacos 3.1.1在集群通信方面做了重大改进：

• 使用gRPC替代部分HTTP通信
• 更频繁的节点健康检查
• 对域名解析的实时性要求更高

这些改进使得DNS缓存问题在3.x版本中被放大。当某个Nacos Pod重启后IP变化，其他节点仍尝试连接旧的IP地址，导致通信失败。

2.3 网络策略与Service配置的影响

不恰当的K8s Service配置会加剧这个问题：

• 使用ClusterIP而非Headless Service
• 未正确设置publishNotReadyAddresses
• 就绪探针(Readiness Probe)配置不合理

3. 终极解决方案实现

3.1 方案一：JVM DNS缓存优化（推荐）

这是最根本的解决方案，通过修改JVM参数调整DNS缓存策略：

# 在Nacos StatefulSet的env中添加 env: - name: JVM_EXTRA_OPTS value: "-Dsun.net.inetaddr.ttl=30 -Dsun.net.inetaddr.negative.ttl=10 -Djava.security.egd=file:/dev/./urandom"

关键参数说明：

• sun.net.inetaddr.ttl=30：设置DNS缓存有效期为30秒
• sun.net.inetaddr.negative.ttl=10：设置解析失败缓存10秒
• java.security.egd：加速JVM启动时的熵值收集

3.2 方案二：K8s服务配置优化

调整Service和StatefulSet配置：

apiVersion: v1 kind: Service metadata: name: nacos-cluster-service spec: clusterIP: None publishNotReadyAddresses: true ports: - port: 8848 name: server selector: app: nacos --- apiVersion: apps/v1 kind: StatefulSet metadata: name: nacos spec: serviceName: nacos-cluster-service replicas: 3 template: spec: dnsConfig: options: - name: ndots value: "2" hostNetwork: false

关键配置点：

• clusterIP: None：使用Headless Service
• publishNotReadyAddresses: true：确保未就绪节点也可被发现
• dnsConfig.options：调整DNS搜索域设置

3.3 方案三：Nacos自定义配置

修改Nacos应用配置：

# application.properties nacos.core.auth.enabled=true nacos.discovery.metadata.preserved.heart.beat.timeout=30000 nacos.naming.clean.task.interval=10

4. 验证与测试方案

4.1 基础功能验证

# 检查集群状态 kubectl exec nacos-0 -- curl -X GET 'http://localhost:8848/nacos/v1/core/cluster/state' # 检查节点列表 kubectl exec nacos-0 -- curl -X GET 'http://localhost:8848/nacos/v1/core/cluster/nodes'

预期输出应显示所有Nacos节点状态为UP。

4.2 故障模拟测试

1. 随机删除一个Pod：

kubectl delete pod nacos-1

2. 观察自动恢复过程：

kubectl logs nacos-0 -f

3. 检查新Pod是否成功加入集群：

kubectl exec nacos-0 -- curl -X GET 'http://localhost:8848/nacos/v1/core/cluster/nodes' | grep new-pod-ip

5. 生产环境注意事项

5.1 性能调优建议

• 根据集群规模调整JVM堆内存：

env: - name: JVM_XMS value: "2g" - name: JVM_XMX value: "2g"

• 对于大型集群（节点数>50），建议：
  • 增加nacos.naming.clean.task.interval至30
  • 调整nacos.core.member.lookup.type为"address-server"

5.2 监控指标配置

建议监控以下关键指标：

• nacos_monitor{name='failedRequestCount'}：失败的集群通信请求
• nacos_monitor{name='ipCheckFailCount'}：IP检查失败次数
• system_cpu_usage：CPU使用率

Prometheus示例配置：

- job_name: 'nacos' metrics_path: '/nacos/actuator/prometheus' static_configs: - targets: ['nacos-cluster-service:8848']

5.3 版本升级策略

从2.x升级到3.1.1时：

1. 先升级一个节点验证兼容性
2. 逐步滚动升级其他节点
3. 特别注意：
   • 数据备份
   • 客户端兼容性
   • 配置项变更

6. 疑难问题排查指南

6.1 常见错误现象与对策

6.2 诊断命令合集

# 检查DNS解析 kubectl exec nacos-0 -- nslookup nacos-cluster-service # 检查网络连通性 kubectl exec nacos-0 -- curl -v http://nacos-1.nacos-cluster-service:8848 # 查看JVM DNS缓存 kubectl exec nacos-0 -- jinfo -flag sun.net.inetaddr.ttl <pid> # 抓包分析 kubectl exec nacos-0 -- tcpdump -i eth0 -w /tmp/dns.pcap kubectl cp nacos-0:/tmp/dns.pcap ./dns.pcap

6.3 日志分析要点

重点关注以下日志模式：

ERROR [com.alibaba.nacos.naming.cluster] - Failed to connect to member: nacos-2.nacos-cluster-service WARN [com.alibaba.nacos.core.cluster] - Address component cannot get local address

这些日志通常伴随解决方案：

1. 检查Pod网络是否正常
2. 验证Service DNS记录
3. 调整集群通信超时参数

7. 架构优化建议

对于生产环境高可用部署，建议采用以下增强架构：

1. 多可用区部署：

spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway

2. 持久化存储优化：

volumeClaimTemplates: - metadata: name: nacos-data spec: storageClassName: local-ssd resources: requests: storage: 50Gi

3. 资源隔离：

resources: limits: cpu: "4" memory: 8Gi requests: cpu: "2" memory: 4Gi

经过上述方案实施后，我们在生产环境中的Nacos 3.1.1集群已经稳定运行6个月，未再出现UnknownHostException问题。关键是要理解K8s的服务发现机制与JVM特性的交互方式，这种跨组件的知识整合往往是解决复杂问题的关键。