Educates培训平台中External-DNS策略的同步问题分析与解决方案

Educates培训平台中External-DNS策略的同步问题分析与解决方案

educates-training-platform A platform for hosting interactive workshop environments in Kubernetes, or on top of a local container runtime. 项目地址: https://gitcode.com/gh_mirrors/ed/educates-training-platform

背景介绍

在Kubernetes集群中，External-DNS是一个常用的组件，用于自动管理DNS记录。Educates培训平台在多个集群共享同一个Route53托管区域时，遇到了DNS记录被意外删除的问题。这是由于External-DNS的同步策略配置不当导致的。

问题分析

当两个或多个Kubernetes集群配置使用相同的Route53托管区域时，如果External-DNS都设置为"sync"策略，每个集群的External-DNS都会认为自己是该区域的唯一管理者。这会导致以下问题：

1. 集群A创建的DNS记录可能被集群B删除
2. 集群B创建的DNS记录可能被集群A删除
3. DNS记录处于不断被删除和重建的不稳定状态

临时解决方案

Educates团队最初采取的临时解决方案是将策略从"sync"回退到"upsert-only"。这种策略下，External-DNS只会创建或更新记录，不会删除任何记录。虽然这解决了记录被意外删除的问题，但并不是最优解决方案，因为它可能导致孤立的DNS记录积累。

根本解决方案

通过研究External-DNS的文档，发现可以通过设置唯一的TXT所有者ID来解决这个问题。具体方案如下：

1. 为每个集群的External-DNS配置不同的txt_owner_id
2. 这个ID在External-DNS部署的生命周期内保持不变
3. 不同集群共享同一DNS区域时，必须使用不同的所有者ID

这种方案的工作原理是：External-DNS会通过TXT记录标记它管理的DNS记录。当使用不同的所有者ID时，每个External-DNS实例只会管理自己创建的记录，不会干扰其他实例管理的记录。

实施建议

对于Educates培训平台，建议采取以下配置：

externalDNS:
  policy: sync
  txtOwnerId: "educates-cluster-1"  # 对第一个集群
  # 或者使用集群唯一标识符
  txtOwnerId: "educates-{{ .Values.clusterId }}"

对于第二个集群：

externalDNS:
  policy: sync
  txtOwnerId: "educates-cluster-2"  # 对第二个集群

结论

通过为每个集群配置唯一的TXT所有者ID，Educates培训平台可以安全地在多个集群间共享Route53托管区域，同时保持"sync"策略的所有优势。这种方案既解决了DNS记录冲突问题，又避免了"upsert-only"策略可能导致的记录积累问题，是更优雅的长期解决方案。

对于正在使用Educates培训平台的用户，建议检查并更新External-DNS的配置，确保每个集群都有唯一的所有者ID，以获得最佳的操作体验和DNS管理效果。

educates-training-platform A platform for hosting interactive workshop environments in Kubernetes, or on top of a local container runtime. 项目地址: https://gitcode.com/gh_mirrors/ed/educates-training-platform