Поделиться через


Настройка пользовательского сопоставителя DNS для кластера Azure Red Hat OpenShift (ARO)

В этой статье содержатся необходимые сведения, позволяющие настроить кластер Azure Red Hat OpenShift (ARO) для использования настраиваемого DNS-сервера. Здесь приводятся требования к кластеру для базового развертывания ARO.

Подготовка к работе

В этой статье предполагается, что вы создаете новый кластер или используете уже существующий кластер с последними обновлениями. Если вам нужен кластер ARO, см. краткое руководство по ARO для общедоступного кластера или руководство по частному кластеру для частного кластера. Приведенные здесь действия по настройке кластера для использования пользовательского DNS-сервера одинаково применимы для частных и общедоступных кластеров.

Проверка совместимости кластера с пользовательским DNS

Убедитесь, что кластер поддерживает эту функцию, проверив наличие объектов machineconfigs: 99-master-aro-dns и 99-worker-aro-dns.

oc get machineconfig

Если результаты приведенной выше команды включают указанные объекты machineconfig, ваш кластер поддерживает пользовательский DNS.

NAME                 GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
...
99-master-aro-dns                                               2.2.0             54d
99-worker-aro-dns                                               2.2.0             54d
...

Обзор архитектуры DNS

Когда какой-либо узел в кластере Azure Red Hat OpenShift включается и присоединяется к сети, служба DHCP настраивает для виртуальной машины такие параметры, как IP-адрес и используемый DNS-сервер.

Ниже приведена схема процесса получения конфигурации.

DNS

Важным компромиссом при использовании собственного DNS-сервера вместо DNS-сервера по умолчанию в виртуальной сети является потеря конфигурации, предоставляемой DNS-сервером. Имена виртуальных машин больше не будут разрешаться через службу DNS в сети.

Общие сведения о процессе обновления

Настройка пользовательского DNS-сервера для кластера разбивается на два этапа.

  1. Изменение параметра конфигурации DNS-серверов виртуальной сети.
  2. Перезапуск узлов в кластере для применения изменений.

Настройка пользовательского DNS-сервера

Следующие шаги можно также выполнить с помощью командной строки, но в этой документации используется веб-интерфейс портала.

Обновление конфигурации DNS в виртуальной сети

Войдите на портал Azure и перейдите к нужной виртуальной сети, которую необходимо изменить. В списке параметров виртуальных сетей выберите DNS-серверы.

Выбор DNS

На экране настройки DNS установите переключатель в положение Настраиваемый. Введите IP-адреса DNS-серверов.

Внимание

Если вы решили указать пользовательский DNS-сервер, вы больше не сможете разрешать имена узлов в виртуальной сети через DNS. Узлы будут доступны только по IP-адресу.

Укажите пользовательские DNS-серверы

Выберите Сохранить.

Примечание.

Как показано в интерфейсе портала, необходимо перезагрузить все виртуальные машины, чтобы применить изменения.

Должно появиться уведомление о том, что обновление прошло успешно.

Подтверждение изменений параметров DNS

Правильная перезагрузка кластера

Для выполнения этих действий требуется действительный файл kubeconfig в кластере. Дополнительные сведения о получении файла kubeconfig см. в этом руководстве.

В следующих фрагментах кода создается объект noop machineconfig для главных и рабочих узлов. Это позволяет инициировать последовательную перезагрузку рабочих или главных узлов. Дополнительные сведения о Machine Config Operator (MCO) см. в исходном коде или документации OpenShift по MCO.

Определения MachineConfig

Перезапуск рабочих узлов

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 25-machineconfig-worker-reboot
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,cmVzdGFydAo=
        filesystem: root
        mode: 0644
        path: /etc/mco-noop-worker-restart.txt

Перезапуск главных узлов

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 25-machineconfig-master-reboot
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,cmVzdGFydAo=
        filesystem: root
        mode: 0644
        path: /etc/mco-master-noop-restart.txt

Перезагрузка рабочих узлов

Создайте файл перезапуска рабочих узлов. В этом примере вызывается и применяется файл worker-restarts.yml.

[user@bastion ~]$ vim worker-restarts.yml
[user@bastion ~]$ oc apply -f worker-restarts.yml
machineconfig.machineconfiguration.openshift.io/25-machineconfig-worker-reboot created

MCO перемещает рабочие нагрузки, а затем перезагружает каждый узел по одному за раз. После возвращения работников в сеть мы будем следовать той же процедуре, чтобы перезагрузить главные узлы. Вы можете проверить состояние рабочих ролей, запросив узлы и убедившись, что они все в Ready состоянии.

Примечание.

В зависимости от размера рабочей нагрузки в кластере для перезагрузки каждого узла может потребоваться несколько минут.

Примеры рабочих узлов, которые не полностью готовы

NAME                                  STATUS                     ROLES    AGE     VERSION
dns-docs-tm45t-master-0               Ready                      master   5h40m   v1.19.0+a5a0987
dns-docs-tm45t-master-1               Ready                      master   5h40m   v1.19.0+a5a0987
dns-docs-tm45t-master-2               Ready                      master   5h40m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus1-8t6q8   Ready                      worker   5h35m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus2-ln2kq   Ready,SchedulingDisabled   worker   5h34m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus3-gg75h   Ready                      worker   5h35m   v1.19.0+a5a0987

После перезагрузки узла вы увидите, что он перейдет в состояние NotReady.

dns-docs-tm45t-worker-eastus2-ln2kq   NotReady,SchedulingDisabled   worker   5h38m   v1.19.0+a5a0987

Полностью готовы

[user@bastion ~]$ oc get nodes
NAME                                  STATUS   ROLES    AGE     VERSION
dns-docs-tm45t-master-0               Ready    master   5h45m   v1.19.0+a5a0987
dns-docs-tm45t-master-1               Ready    master   5h46m   v1.19.0+a5a0987
dns-docs-tm45t-master-2               Ready    master   5h46m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus1-8t6q8   Ready    worker   5h41m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus2-ln2kq   Ready    worker   5h40m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus3-gg75h   Ready    worker   5h41m   v1.19.0+a5a0987

Перезагрузка главных узлов

Теперь повторите ту же процедуру для главных узлов.

[user@bastion ~]$ vim master-restarts.yml
[user@bastion ~]$ oc apply -f master-restarts.yml
machineconfig.machineconfiguration.openshift.io/25-machineconfig-master-reboot created

Убедитесь, что все узлы вернулись в состояние Ready.

[user@bastion ~]$ oc get nodes
NAME                                  STATUS   ROLES    AGE    VERSION
dns-docs-tm45t-master-0               Ready    master   6h8m   v1.19.0+a5a0987
dns-docs-tm45t-master-1               Ready    master   6h8m   v1.19.0+a5a0987
dns-docs-tm45t-master-2               Ready    master   6h8m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus1-8t6q8   Ready    worker   6h3m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus2-ln2kq   Ready    worker   6h2m   v1.19.0+a5a0987
dns-docs-tm45t-worker-eastus3-gg75h   Ready    worker   6h3m   v1.19.0+a5a0987

Проверка правильности изменений в узле (необязательно)

Чтобы проверить новый DNS-сервер на узле, воспользуемся модулем pod oc debug.

[user@bastion ~]$ oc debug node/dns-docs-tm45t-worker-eastus2-ln2kq
Starting pod/dns-docs-tm45t-worker-eastus2-ln2kq-debug ...
To use host binaries, run `chroot /host`
chroot Pod IP: 10.0.2.6
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-4.4# uptime
 18:40:16 up 1 min,  0 users,  load average: 0.82, 0.32, 0.12
sh-4.4# cat /etc/resolv.conf.dnsmasq
# Generated by NetworkManager
search reddog.microsoft.com
nameserver 192.168.0.1

Изменение пользовательского DNS-сервера

Процедура изменения пользовательского DNS в кластере, в котором уже есть пользовательский DNS, выполняется аналогично.

Изменение DNS

Выполните процедуру, описанную здесь, чтобы изменить конфигурацию DNS в виртуальной сети.

Перезагрузка узлов

Вместо создания machineconfig мы удалим файлы machineconfig,созданные нами в первый раз. Начнем с рабочих узлов.

oc delete machineconfig 25-machineconfig-worker-reboot

Результаты:

machineconfig.machineconfiguration.openshift.io "25-machineconfig-worker-reboot" deleted

Дождитесь перезагрузки всех рабочих узлов. Это аналогично перезагрузке рабочих узлов выше.

Теперь перезагрузим главные узлы.

oc delete machineconfig 25-machineconfig-master-reboot

Результаты:

machineconfig.machineconfiguration.openshift.io "25-machineconfig-master-reboot" deleted

Дождитесь перезагрузки всех главных узлов и их возвращения в состояние Ready.