Apache DolphinScheduler 3.2.2 在 Kubernetes 环境中 AlertServer 服务注册问题解析与解决方案

问题背景

在 Kubernetes 环境中部署 Apache DolphinScheduler 3.2.2 版本时，AlertServer 服务会将其 Pod 名称（如 alert-server-7d6f7b8d8f-zc4h9）注册到 Zookeeper 中。这种注册方式会导致其他组件（如 API Server）无法正确解析该地址，从而引发告警功能失效的问题。

问题原因分析

在 Kubernetes 环境中，Pod 名称是动态生成的，且仅在 Pod 所属的命名空间内可解析。当 AlertServer 将其 Pod 名称注册到 Zookeeper 后，其他组件尝试通过该名称访问 AlertServer 时会遇到以下问题：

1. 跨命名空间解析问题：Kubernetes 默认情况下不允许跨命名空间解析 Pod 名称
2. 动态性问题：Pod 名称会随着重启或重新调度而改变
3. 服务发现机制不匹配：Zookeeper 中注册的地址应该是稳定可访问的服务端点

解决方案

方案一：配置网络接口参数

通过修改 DolphinScheduler 的通用配置文件，可以指定网络接口参数：

# 网络接口首选项配置
dolphin.scheduler.network.interface.preferred=

# 网络接口限制配置
dolphin.scheduler.network.interface.restrict=docker0

这个配置可以帮助系统选择正确的网络接口进行注册。

方案二：添加环境变量

在 AlertServer 的部署配置中添加以下环境变量：

env:
- name: spring.cloud.kubernetes.enabled
  value: 'false'

这个配置可以禁用 Kubernetes 的服务发现机制，使系统使用更传统的服务注册方式。

方案三：手动配置 hosts 映射

在 API Server 的容器中，手动将 AlertServer 的 Pod 名称映射到其对应的服务 IP 地址：

1. 获取 AlertServer 的 Service ClusterIP
2. 编辑 API Server 容器的 /etc/hosts 文件，添加如下条目：

<ClusterIP> alert-server-7d6f7b8d8f-zc4h9

方案四：使用 StatefulSet 和 Headless Service

采用 StatefulSet 部署 AlertServer 并配合 Headless Service，可以提供更稳定的网络标识：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dolphin-alert
spec:
  serviceName: dolphin-alert
  template:
    spec:
      setHostnameAsFQDN: true
---
apiVersion: v1
kind: Service
metadata:
  name: dolphin-alert
spec:
  clusterIP: None
  ports:
    - port: 50052
      targetPort: 50052
  publishNotReadyAddresses: true

最佳实践建议

1. 生产环境推荐：采用方案四的 StatefulSet + Headless Service 组合，这是 Kubernetes 原生推荐的有状态服务部署方式
2. 测试环境可选：方案二的环境变量配置简单快捷，适合快速验证
3. 避免方案三：手动维护 hosts 映射虽然能解决问题，但不利于自动化管理和扩展

问题预防

在未来的版本部署中，建议：

1. 提前规划 Kubernetes 服务发现机制
2. 验证各组件间的网络连通性
3. 考虑使用 Service Mesh 技术统一管理服务通信

总结

Apache DolphinScheduler 在 Kubernetes 环境中的部署需要特别注意服务注册和发现的机制。AlertServer 的 Pod 名称注册问题是一个典型的云原生环境适配问题，通过合理的 Kubernetes 资源定义和网络配置，可以确保告警功能的稳定运行。理解这些解决方案背后的原理，有助于我们在其他类似场景中快速定位和解决问题。