本文介绍在部署大数据群集时适应 Active Directory 集成的一些难题和解决方案。
重要
Microsoft SQL Server 2019 大数据群集附加产品将停用。 对 SQL Server 2019 大数据群集的支持将于 2025 年 2 月 28 日结束。 具有软件保障的 SQL Server 2019 的所有现有用户都将在平台上获得完全支持，在此之前，该软件将继续通过 SQL Server 累积更新进行维护。 有关详细信息，请参阅公告博客文章和 Microsoft SQL Server 平台上的大数据选项。
概述
如果未使用 Active Directory 集成部署大数据群集，我们将依赖于 Kubernetes CoreDNS 服务进行内部 DNS 解析。 Kubernetes 使用内部域，例如 <namespace>.svc.cluster.local。 它在 DNS 服务器中创建具有此域中名称的 A（正向查找）和 PTR （反向查找）记录。
但是，启用 Active Directory 模式后，将会出现带有其自身 DNS 服务器集的新域。 在内部名称解析期间，这可能会导致涉及到哪个 DNS 服务器集用于正向和反向查找的问题出现混淆。
挑战
- 部署新的 Kubernetes Pod 时，需要在这两组 DNS 服务器中添加 DNS 条目。 Kubernetes 负责记录 CoreDNS 中的条目，但 BDC 部署工作流负责在 Active Directory 域控制器 DNS 服务器中添加所需的条目。 同样，删除大数据群集时，工作流必须确保删除这些条目。
- Active Directory DNS 服务器位于 Kubernetes 群集外部。 但 BDC 在 Kubernetes 中有自己的 IP 空间，并且无法在位于外部的 DNS 服务器中创建此 IP 空间的记录，因为此 IP 空间在群集边界之外不可见。
- 在 Kubernetes 群集中发生故障转移事件时，还必须更新 AD DNS 服务器中的记录。
- 除了 Pod 名称，Kubernetes 服务名称还必须可通过 AD 域名查找进行寻址。 这会在 Active Directory DNS 中创建额外的挑战，因为一个服务名称可以映射到多个 Pod IP 地址。
- 组织 Active Directory DNS 服务器中的记录更新传播和复制延迟可能非常重要，并且无法控制 BDC 管理工作流。 这可能会在部署和故障转移时立即影响 BDC 的功能。 相反，由于 Kubernetes CoreDNS 的本地性，Kubernetes CoreDNS 速度更快且高效。
解决方案
为了解决上述挑战，在 BDC 中实现的解决方案涉及在 BDC 命名空间中管理的新内部 CoreDNS 服务。 这是 BDC 命名空间中的 Pod 用于进行名称解析的唯一 DNS 服务。 多个域的复杂性隐藏在新 CoreDNS 服务后面。
例如，在下图中，Pod 使用 BDC CoreDNS 服务器解析名称。 Pod 不直接与 Kubernetes CoreDNS 服务器或 AD DNS 服务器交互。
下面是一些实现细节，其中阐明了此设计在 BDC 中的工作原理：
多个域的集中管理
名称查找上发生的情况的复杂性仍以集中方式隐藏在内部 DNS 服务后面。 这样就避免了使各个 Pod 承担多个域的管理负担，并简化了设计。
外部 DNS 服务器中没有关于内部 Pod 的记录
由于此设计原则，BDC 不必为外部 DNS 服务器 Kubernetes IP 空间中的 Pod 创建和管理 A 和 PTR 记录。
不重复记录
多个地点的内部 DNS 记录。 这些记录的唯一存储是 Kubernetes CoreDNS。 BDC 内部 CoreDNS 将执行 DNS 查询的计算重写和转发到 Kubernetes CoreDNS。
计算重写
由于 BDC 不存储任何记录，因此 BDC 负责将具有 AD 域的名称的传入转发查找查询转换为 Kubernetes 域的名称，并将此查询转发到 Kubernetes CoreDNS。
例如，将传入查询compute-0-0.contoso.local重写为compute-0-0.compute-0-svc.contoso.svc.cluster.local，并将此请求转发到 Kubernetes CoreDNS。
对于反向查找，请求会连同内部 IP 一同直接转发到 Kubernetes CoreDNS，然后在响应客户端之前，将返回的信息重写为 AD 域名。
Pod 配置中的简单性
由于所有 BDC Pod 的 /etc/resolv.conf 中仅引用了内部 BDC CoreDNS，因此这简化了 Pod 中的网络视图。 复杂性将隐藏在内部 CoreDNS 中。
DNS 服务的静态和可靠 IP 地址
BDC 部署的 CoreDNS 服务将注册可从所有 Pod 访问的静态内部 IP。 这将确保 /etc/resolv.conf 中的值不必更新。
Kubernetes 保留服务负载均衡管理
当服务而不是单个 Pod 进行查找时，它们仍将转到 Kubernetes CoreDNS，因此 BDC 不负责为 AD 域实现负载均衡。
例如，如果正向查找请求出现 compute-0-svc.contoso.local，则会将其重写为 compute-0-svc.contoso.svc.cluster.local。 此请求将转发到 Kubernetes CoreDNS，负载均衡将在那里进行。 响应将是多个计算池实例中的一个（Pod 副本）的 IP 地址。
可伸缩性
由于 BDC 不存储任何记录，因此无需状态保留和跨多个副本进行记录复制即可缩放内部 BDC CoreDNS。 如果 DNS 记录会存储在 BDC 中，那么 BDC 还必须负责在所有 Pod 间复制状态。
外部可见的服务条目保留在 AD DNS 中
对于需要可供 Kubernetes 群集外部客户端访问的服务终结点，将在部署 BDC 时在 AD DNS 服务器中创建 DNS 条目。 用户将通过部署配置文件输入要从中注册的 DNS 名称。
自我取消预配
删除 BDC 后，取消预配群集时，不会进行额外的动态工作来删除 DNS 条目。 需要清理的远程 Active Directory DNS 中唯一的条目用于外部服务，它们是静态的。 内部 DNS 条目将自动随群集一起删除。