Uptime Kuma在K3s环境中Slack通知证书错误的解决方案

问题背景

在使用Uptime Kuma进行服务监控时，许多用户会选择将其部署在Kubernetes环境中。近期有用户报告，在K3s集群中部署Uptime Kuma后，配置Slack通知时遇到了"self-signed certificate"错误，尽管通过curl命令测试Slack Webhook可以正常工作。

问题分析

经过深入调查，发现这个问题与K3s特有的DNS解析机制有关。K3s默认会将宿主机的resolv.conf文件引入容器中，包括其中配置的搜索域(search domain)。这会导致一个特殊的DNS解析行为：

1. 当应用程序尝试访问外部服务(如Slack API)时
2. K3s的CoreDNS会将请求域名与搜索域组合
3. 例如访问https://google.com实际上会变成https://google.com.search.domain.com
4. 这种错误的解析会导致连接到错误的端点，从而触发证书验证失败

解决方案

针对这个问题，可以通过以下步骤解决：

1. 修改K3s的DNS配置：

   • 创建自定义的resolv.conf文件
   • 移除不必要的搜索域配置
   • 确保只保留必要的nameserver配置

2. 具体实施步骤：

   • 在K3s节点上创建新的resolv.conf文件
   • 配置K3s使用这个自定义的DNS配置
   • 重新部署Uptime Kuma

3. 验证解决方案：

   • 在容器内执行nslookup测试
   • 确认域名解析正确
   • 再次测试Slack通知功能

技术原理

K3s的这种行为源于其设计理念，它试图简化Kubernetes的部署，但有时会带来一些非标准的实现。特别是：

• 默认继承宿主机的DNS配置
• CoreDNS的特殊解析逻辑
• 搜索域的自动追加行为

这些特性在某些网络环境下可能会导致意外的解析结果，特别是当访问外部服务时。

最佳实践建议

对于在K3s上部署Uptime Kuma的用户，建议：

1. 始终检查容器内的DNS解析行为
2. 对于关键外部服务，考虑使用完全限定域名(FQDN)
3. 定期验证通知渠道的工作状态
4. 考虑使用K3s的DNS自定义配置选项

通过理解K3s的这些特殊行为，用户可以更好地配置和维护他们的监控系统，确保通知功能稳定可靠。