Настройка пользовательского сопоставителя 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-серверов виртуальной сети.
- Перезапуск узлов в кластере для применения изменений.
Настройка пользовательского DNS-сервера
Следующие шаги можно также выполнить с помощью командной строки, но в этой документации используется веб-интерфейс портала.
Обновление конфигурации DNS в виртуальной сети
Войдите на портал Azure и перейдите к нужной виртуальной сети, которую необходимо изменить. В списке параметров виртуальных сетей выберите DNS-серверы.
На экране настройки DNS установите переключатель в положение Настраиваемый. Введите IP-адреса DNS-серверов.
Внимание
Если вы решили указать пользовательский DNS-сервер, вы больше не сможете разрешать имена узлов в виртуальной сети через DNS. Узлы будут доступны только по IP-адресу.
Выберите Сохранить.
Примечание.
Как показано в интерфейсе портала, необходимо перезагрузить все виртуальные машины, чтобы применить изменения.
Должно появиться уведомление о том, что обновление прошло успешно.
Правильная перезагрузка кластера
Для выполнения этих действий требуется действительный файл 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.