Выверка DNS Active Directory и Kubernetes в развертываниях кластеров больших данных
В этой статье описываются некоторые проблемы и решения по интеграции Active Directory при развертывании Кластеров больших данных.
Важно!
Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, а программное обеспечение будет продолжать поддерживаться через SQL Server накопительных обновлений до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.
Обзор
Если кластер больших данных развертывается не с интеграцией Active Directory, мы используем службу Kubernetes CoreDNS для внутренних разрешений DNS. Kubernetes использует внутренний домен, например <namespace>.svc.cluster.local. Он создает записи A (прямой просмотр) и PTR (обратный просмотр) на DNS-сервере с именами в этом домене.
Однако если включен режим Active Directory, необходимо учитывать новый домен с собственным набором DNS-серверов. Во время внутреннего разрешения имен это может привести к путанице относительно того, какой набор DNS-серверов использовать для прямых и обратных просмотров.
Сложности
- При развертывании новых модулей pod Kubernetes необходимо добавить записи DNS в оба набора DNS-серверов. Kubernetes следит за фиксацией записей в CoreDNS, однако рабочий процесс развертывания кластеров больших данных отвечает за добавление необходимых записей в DNS-серверы контроллера домена Active Directory. Аналогичным образом при удалении кластера больших данных этот процесс должен гарантировать удаление этих записей.
- DNS-серверы Active Directory являются внешними по отношению к кластеру Kubernetes. Но у кластера больших данных есть собственное пространство IP-адресов внутри Kubernetes, и он не может создавать записи для этого пространства IP-адресов на внешнем DNS-сервере, так как это пространство IP-адресов не отображается за пределами границ кластера.
- При возникновении событий отработки отказа в кластере Kubernetes необходимо также обновить записи на DNS-серверах AD.
- Помимо имен pod, имена служб Kubernetes также должны быть доступны для обращения с помощью просмотра доменных имен Active Directory. Это создает дополнительные сложности в Active Directory DNS, так как одно имя службы может сопоставляться с несколькими IP-адресами модуля pod.
- Задержки в репликации и распространении обновления записи в организационных DNS-серверах Active Directory могут быть значительными и не контролируются рабочими процессами управления кластера больших данных. Это может повлиять на функциональность кластера больших данных сразу после развертывания и отработки отказа. Kubernetes CoreDNS, наоборот, работает быстрее и эффективнее благодаря локальному размещению.
Решение
Чтобы устранить эти проблемы, в кластере больших данных используется новая внутренняя служба CoreDNS, которая управляется внутри пространства имен кластера больших данных. Это единственная служба DNS, к которой будут обращаться модули pod в пространстве имен кластера больших данных для разрешения имен. Служба CoreDNS упрощает использование системы из нескольких доменов.
Например, на следующей схеме для разрешения имен в модулях pod используется сервер CoreDNS кластера больших данных. Модули pod не взаимодействуют напрямую с сервером Kubernetes CoreDNS или DNS-сервером Active Directory.
Ниже приведены некоторые сведения о реализации, которые поясняют, как работает эта схема в кластере больших данных:
Централизованное управление несколькими доменами
Сложные операции с просмотром имен централизованно выполняются внутренней службой DNS. Это позволяет избежать сложного управления несколькими доменами в отдельных модулях pod и упрощает систему.
Отсутствие записей для внутренних модулей pod на внешних DNS-серверах
В результате этого принципа проектирования кластер больших данных не будет создавать записи A и PTR и управлять ими для модулей pod в пространстве IP-адресов Kubernetes на внешних DNS-серверах.
Отсутствие дублирования записей
Внутренние записи DNS находятся в нескольких местах. Единственным хранилищем для этих записей является Kubernetes CoreDNS. Внутренний CoreDNS в кластере больших данных выполняет вычислительное переопределение и перенаправление запросов DNS в Kubernetes CoreDNS.
Вычислительное переопределение
Так как в кластере больших данных не хранятся никакие записи, он переводит входящие запросы прямого просмотра с именами, где указан домен 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
Так как только внутренний CoreDNS кластера больших данных указан в /etc/resolv.conf во всех модулях pod кластера больших данных, картина сети с точки зрения pod упрощается. Вся сложность скрыта во внутреннем CoreDNS.
Статический и надежный IP-адрес для службы DNS
Служба CoreDNS, которую развертывает кластер больших данных, будет иметь зарегистрированный статический внутренний IP-адрес, доступ к которому можно получить из всех модулей pod. Благодаря этому можно не обновлять значения в /etc/resolv.conf.
Управление балансировкой нагрузки службы поддерживается с помощью Kubernetes
Когда выполняется просмотр для служб, а не отдельных модулей pod, запросы по-прежнему направляются в Kubernetes CoreDNS, поэтому кластер больших данных не занимается реализацией балансировки нагрузки специально для домена AD.
Например, если поступает запрос прямого просмотра для compute-0-svc.contoso.local, он будет преобразован в compute-0-svc.contoso.svc.cluster.local. Этот запрос будет перенаправлен в Kubernetes CoreDNS, где и будет осуществляться балансировка нагрузки. Ответ будет представлять собой IP-адрес одного из нескольких экземпляров вычислительного пула (реплики pod).
Масштабируемость
Так как в кластере больших данных не хранятся никакие записи, внутренний CoreDNS кластера больших данных можно масштабировать без сохранения состояния и репликации записей между несколькими репликами. Если записи DNS будут храниться в кластере больших данных, репликация состояния по всем модулям pod также должна будет учитывать кластер больших данных.
Записи служб, доступные извне, остаются в AD DNS
Для конечных точек служб, которые должны быть доступны клиентам за пределами кластера Kubernetes, при развертывании кластера больших данных на DNS-сервере Active Directory будут созданы записи DNS. Пользователь будет вводить DNS-имена для регистрации в профилях конфигурации развертывания.
Автоматический отзыв
После удаления кластера больших данных не нужно выполнять дополнительные динамические задачи по удалению записей DNS при отзыве кластера. Единственными записями в удаленном DNS Active Directory, которые необходимо очистить, являются внешние службы, а их число статично. Внутренние DNS-записи будут автоматически удалены вместе с кластером.