Konfigurowanie niestandardowego rozpoznawania nazw DNS dla klastra usługi Azure Red Hat OpenShift (ARO)
Ten artykuł zawiera niezbędne szczegóły, które umożliwiają skonfigurowanie klastra Azure Red Hat OpenShift (ARO) do używania niestandardowego serwera DNS. Zawiera wymagania dotyczące klastra dla podstawowego wdrożenia usługi ARO.
Zanim rozpoczniesz
W tym artykule założono, że tworzysz nowy klaster lub masz istniejący klaster z zastosowanymi najnowszymi aktualizacjami. Jeśli potrzebujesz klastra usługi ARO, zobacz przewodnik Szybki start usługi ARO dla klastra publicznego lub samouczek dotyczący klastra prywatnego dla klastra prywatnego. Te kroki konfigurowania klastra w celu używania niestandardowego serwera DNS są takie same zarówno w przypadku klastrów prywatnych, jak i publicznych.
Potwierdzanie zgodności klastra z niestandardowym systemem DNS
Upewnij się, że klaster kwalifikuje się do obsługi tej funkcji, sprawdzając istnienie elementów 99-master-aro-dns i 99-worker-aro-dns machineconfigs.
oc get machineconfig
Jeśli wyniki powyższego polecenia obejmują następujące konfiguracje maszyn, klaster kwalifikuje się do obsługi niestandardowej usługi DNS.
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE
...
99-master-aro-dns 2.2.0 54d
99-worker-aro-dns 2.2.0 54d
...
Omówienie architektury DNS
Ponieważ każdy węzeł w klastrze Azure Red Hat OpenShift włącza i dołącza do sieci, dhcp konfiguruje maszynę wirtualną z informacjami, takimi jak adres IP i który serwer DNS ma być używany.
Poniżej przedstawiono przegląd przepływu procesów dotyczący sposobu uzyskiwania konfiguracji:
Ważnym kompromisem podczas korzystania z własnego serwera DNS zamiast domyślnego serwera DNS w sieci wirtualnej jest utrata konfiguracji dostarczonej przez serwer DNS. Nazwy maszyn wirtualnych nie będą już rozpoznawane za pośrednictwem systemu DNS w sieci.
Omówienie procesu aktualizacji
Konfigurowanie niestandardowego serwera DNS dla klastra jest podzielone na dwa kroki.
- Modyfikowanie ustawienia konfiguracji serwerów DNS sieci wirtualnej.
- Ponowne uruchamianie węzłów w klastrze w celu wprowadzania zmian.
Konfigurowanie niestandardowego serwera DNS
Poniższe kroki można również wykonać za pomocą wiersza polecenia, ale ta dokumentacja będzie przechodzić przy użyciu interfejsu internetowego portalu.
Aktualizowanie konfiguracji DNS w sieci wirtualnej
Zaloguj się do witryny Azure Portal i przejdź do żądanej sieci wirtualnej, którą chcesz zaktualizować. Wybierz pozycję Serwery DNS z listy ustawień sieci wirtualnych.
Po przejściu na ekranie konfiguracji DNS wybierz pozycję Niestandardowy z konfiguracji przycisku promieniowego. Wprowadź adresy IP dla serwerów DNS.
Ważne
Jeśli zdecydujesz się określić niestandardowy serwer DNS, nie będzie już można rozpoznać nazw węzłów w sieci wirtualnej za pośrednictwem systemu DNS. Węzły będą dostępne tylko za pośrednictwem adresu IP.
Wybierz pozycję Zapisz.
Uwaga
Jak pokazano w interfejsie portalu, należy ponownie uruchomić wszystkie maszyny wirtualne, aby zmiany zostały wprowadzone.
Powinno zostać wyświetlone powiadomienie o pomyślnym zakończeniu aktualizacji.
Bezproblemowy ponowny rozruch klastra
Te kroki wymagają prawidłowej konfiguracji kubeconfig w klastrze. Zobacz ten samouczek , aby uzyskać szczegółowe informacje na temat uzyskiwania narzędzia kubeconfig.
Poniższe fragmenty kodu tworzą noop machineconfigdla węzłów głównych i roboczych. Umożliwia to zainicjowanie ponownego uruchomienia operacyjnego dla węzłów roboczych lub głównych. Aby uzyskać więcej informacji na temat operatora konfiguracji maszyny (MCO), zobacz kod źródłowy lub dokumentację openShift dla MCO .
Definicje konfiguracji maszyny
Proces roboczy jest uruchamiany ponownie:
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
Główne ponowne uruchomienia:
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
Ponowne uruchamianie węzłów roboczych
Utwórz plik ponownego uruchomienia procesu roboczego, w tym przykładzie wywołaj plik worker-restarts.ymli zastosuj go.
[user@bastion ~]$ vim worker-restarts.yml
[user@bastion ~]$ oc apply -f worker-restarts.yml
machineconfig.machineconfiguration.openshift.io/25-machineconfig-worker-reboot created
McO przenosi obciążenia, a następnie ponownie uruchamia każdy węzeł pojedynczo. Po powrocie procesów roboczych do trybu online wykonamy tę samą procedurę, aby ponownie uruchomić węzły główne. Stan procesów roboczych można sprawdzić, wysyłając zapytanie do węzłów i sprawdzając, czy wszystkie są w Ready stanie.
Uwaga
W zależności od rozmiaru obciążenia, które ma klaster, ponowne uruchomienie każdego węzła może potrwać kilka minut.
Przykładowe węzły robocze nie są w pełni gotowe:
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
Podczas ponownego uruchamiania węzła zobaczysz, że zmieni się on na stan NotReady:
dns-docs-tm45t-worker-eastus2-ln2kq NotReady,SchedulingDisabled worker 5h38m v1.19.0+a5a0987
W pełni gotowe:
[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
Ponowne uruchamianie węzłów głównych
Teraz powtórz ten sam proces dla węzłów głównych:
[user@bastion ~]$ vim master-restarts.yml
[user@bastion ~]$ oc apply -f master-restarts.yml
machineconfig.machineconfiguration.openshift.io/25-machineconfig-master-reboot created
Upewnij się, że wszystkie węzły zostały zwrócone do Ready stanu:
[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
Potwierdzanie zmian w węźle (opcjonalnie)
Aby zweryfikować nowy serwer DNS w węźle, użyjemy zasobnika 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
Modyfikowanie niestandardowego serwera DNS
Procedura modyfikowania niestandardowego systemu DNS w klastrze, który ma już niestandardowy system DNS, jest zgodny z tym samym procesem.
Modyfikowanie systemu DNS
Postępuj zgodnie z procedurą opisaną tutaj , aby zaktualizować konfigurację DNS w sieci wirtualnej.
Ponowny rozruch węzłów
Zamiast tworzyć element machineconfig, zamiast tego usuniemy s machineconfig, które utworzyliśmy po raz pierwszy. Zaczniemy od węzłów roboczych.
oc delete machineconfig 25-machineconfig-worker-reboot
Dane wyjściowe:
machineconfig.machineconfiguration.openshift.io "25-machineconfig-worker-reboot" deleted
Poczekaj na ponowne uruchomienie wszystkich węzłów procesu roboczego. Jest to podobne do ponownego uruchamiania węzłów roboczych powyżej.
Teraz uruchomimy ponownie węzły główne.
oc delete machineconfig 25-machineconfig-master-reboot
Dane wyjściowe:
machineconfig.machineconfiguration.openshift.io "25-machineconfig-master-reboot" deleted
Poczekaj na ponowne uruchomienie wszystkich węzłów głównych i wróć do stanu Gotowe.