Configurare un risolutore Domain Name Server personalizzato per il cluster di Azure Red Hat OpenShift (ARO)

Questo articolo fornisce i dettagli necessari che consentono di configurare il cluster di Azure Red Hat OpenShift (ARO) per usare un server DNS personalizzato. Contiene i requisiti del cluster per una distribuzione di ARO di base.

Operazioni preliminari

Questo articolo presuppone che si intenda creare un nuovo cluster o che si abbia già un cluster con gli aggiornamenti più recenti applicati. Se è necessario un cluster di Azure Red Hat Openshift (ARO), vedere la guida introduttiva di ARO per un cluster pubblico o l'esercitazione sul cluster privato per un cluster privato. Questa procedura per configurare il cluster per l'uso di un server DNS personalizzato non presenta differenze per i cluster privati e pubblici.

Verificare la compatibilità del cluster con DNS personalizzato

Verificare che il cluster sia idoneo a supportare questa funzionalità convalidando l'esistenza di machineconfigs 99-master-aro-dns e 99-worker-aro-dns.

oc get machineconfig

Se i risultati del comando precedente includono le machineconfig seguenti, il cluster è idoneo per il supporto DNS personalizzato.

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

Panoramica dell'architettura DNS

Quando ogni nodo del cluster di Azure Red Hat OpenShift si accende e accede alla rete, DHCP configura la macchina virtuale con informazioni quali l'indirizzo IP e il server DNS da usare.

Ecco la panoramica del flusso di processo che spiega come viene ottenuta la configurazione:

DNS

Una conseguenza importante quando si usa il proprio server DNS invece del server DNS predefinito nella rete virtuale è che si perde la configurazione fornita dal server DNS. I nomi delle macchine virtuali non verranno più risolti tramite DNS nella rete.

Panoramica del processo di aggiornamento

La configurazione di un server DNS personalizzato per il cluster viene suddivisa in due passaggi.

  1. Modifica dell'impostazione di configurazione dei server DNS della rete virtuale.
  2. Riavvio dei nodi nel cluster per apportare modifiche.

Configurare un server DNS personalizzato

I passaggi seguenti possono essere eseguiti anche tramite la riga di comando, ma in questa documentazione viene spiegato come eseguirli nell'interfaccia Web del portale.

Aggiornare la configurazione DNS nella rete virtuale

Accedere al portale di Azure e passare alla rete virtuale desiderata da aggiornare. Selezionare Server DNS nell'elenco delle impostazioni delle reti virtuali.

Selezionare DNS

Nella schermata di configurazione DNS selezionare Personalizzata nella configurazione del pulsante di opzione. Immettere gli indirizzi IP per i server DNS.

Importante

Se si sceglie di specificare un server DNS personalizzato, non sarà più possibile risolvere i nomi dei nodi nella rete virtuale tramite DNS. I nodi saranno raggiungibili solo tramite l'indirizzo IP.

Specificare server DNS personalizzati

Seleziona Salva.

Nota

Come illustrato nell'interfaccia del portale, è necessario riavviare tutte le macchine virtuali per rendere effettive le modifiche.

Si dovrebbe ricevere una notifica che informa che l'aggiornamento è riuscito.

Confermare le modifiche DNS

Riavviare normalmente il cluster

Questa procedura richiese un kubeconfig valido per il cluster. Vedere questa esercitazione per informazioni dettagliate su come ottenere un kubeconfig.

I frammenti di codice seguenti consentono di creare machineconfig noop per i nodi master e di lavoro. In questo modo è possibile avviare riavvii in sequenza per i nodi master o di lavoro. Per altre informazioni sull'operatore MachineConfig (MCO), vedere il codice sorgente o la documentazione di OpenShift relativa a MCO.

Definizioni di MachineConfig

Riavvio del nodo di lavoro:

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

Riavvio del nodo master:

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

Riavviare i nodi di lavoro

Creare il file di riavvio del nodo di lavoro e applicarlo. In questo esempio viene chiamato il file 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

L'operatore MCO sposta i carichi di lavoro e quindi riavvia ogni nodo uno alla volta. Una volta che i nodi di lavoro sono tornati online, si seguirà la stessa procedura per riavviare i nodi master. È possibile verificare lo stato dei nodi di lavoro eseguendo una query sui nodi e convalidare che lo stato sia Ready per tutti i nodi.

Nota

A seconda delle dimensioni del carico di lavoro del cluster, il riavvio di ogni nodo può richiedere alcuni minuti.

Nodi di lavoro di esempio non completamente pronti:

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

Al riavvio del nodo verrà visualizzato lo stato NotReady:

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

Completamente pronto:

[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

Riavviare i nodi master

Ripetere ora lo stesso processo per i nodi master:

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

Verificare che tutti i nodi siano tornati allo stato 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

Verificare le modifiche in un nodo (facoltativo)

Per convalidare il nuovo server DNS in un nodo, verrà usato il 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

Modifica del server DNS personalizzato

La procedura di modifica del DNS personalizzato in un cluster con DNS personalizzato sul posto segue lo stesso processo.

Modificare il DNS

Seguire la procedura descritta qui per aggiornare la configurazione DNS nella rete virtuale.

Riavviare i nodi

Invece di creare machineconfig, si elimineranno invece le machineconfigcreata la prima volta. Si inizierà con i nodi di lavoro.

oc delete machineconfig 25-machineconfig-worker-reboot

L'output è:

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

Attendere il riavvio di tutti i nodi di lavoro. Questo comportamento è simile al riavvio dei nodi di lavoro descritto in precedenza.

A questo punto verranno riavviati i nodi master.

oc delete machineconfig 25-machineconfig-master-reboot

L'output è:

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

Attendere che tutti i nodi master vengano riavviati e tornino allo stato Ready.