Perché vedo errori DNS dopo l'aggiunta di un resolver DNS personalizzato?

Virtual Private Cloud4.15 e versioni successive

Si verificano errori DNS dopo aver creato un resolver DNS personalizzato nella VPC in cui esiste già un cluster 4.15.

Risolvi i problemi relativi alla configurazione DNS personalizzata con lo stocc Satellite.

In ognuno dei seguenti casi, sincronizzando il gruppo di sicurezza kube-<clusterID> e sostituendo i nodi di lavoro come descritto nei seguenti passi. Si noti che il problema potrebbe non manifestarsi immediatamente dopo la creazione e l'attivazione del resolver nella VPC. DNS include una cache che potrebbe risolvere la ricerca del nome fino a quando un nodo di lavoro non viene sostituito o riavviato o i pod non vengono riavviati.

  • L'aggiunta o la sostituzione di un nodo di lavoro al cluster non riesce e ibmcloud ks workers mostra lo stato di un nodo di lavoro simile al seguente
    Infrastructure instance status is 'failed': Can't start instance because provisioning failed.
  • Eseguendo oc get oc viene visualizzato un errore simile al seguente.
    dial tcp: lookup s3.direct.eu-de.cloud-object-storage.appdomain.cloud on 172.21.0.10:53: server misbehaving.
  • Il riavvio di un worker comporta che i pod su quel worker entrino nello stato “ Terminating ”, che la console web OpenShift non si apra più o che Ingress si trovi nello stato “ Critical ”.

Se nella VPC è stato abilitato un resolver DNS personalizzato prima di creare un cluster 4.15, Red Hat OpenShift on IBM Cloud aggiunge automaticamente le regole per consentire il traffico attraverso gli indirizzi IP del resolver DNS al gruppo di sicurezza gestito IBM Cloud (kube-<clusterID>).

Tuttavia, se abiliti un resolver DNS personalizzato su un VPC che contiene già un cluster 4.15, tali cluster esistenti perdono accesso al DNS.

Per risolvere questo problema, consenti l'accesso ai resolver DNS sui cluster esistenti sincronizzando il gruppo di protezione kube-<clusterID>. La sincronizzazione del gruppo di sicurezza “ kube-<clusterID> ” aggiunge regole che consentono il passaggio del traffico attraverso gli indirizzi IP dei resolver DNS

  1. Trova l'ID del tuo gruppo di protezione kube-<clusterID>.

    ibmcloud is security-groups

  2. Sincronizza il gruppo di protezione.

    ibmcloud oc security-group sync --cluster <clusterID> --security-group <security-group-ID>

  3. Sostituisci i nodi di lavoro del tuo cluster.

    ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>

  4. Se il problema persiste, contattare il supporto. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere i file di log, i messaggi di errore o gli output dei comandi pertinenti.

Altri scenari

Condizioni di errore che potrebbero essere dovute alla combinazione di un resolver DNS personalizzato nei cluster VPC e 4.15 nello stesso VPC.

Se il cluster viene creato dopo la creazione del resolver DNS

Se crei un cluster 4.15 dopo aver creato un resolver DNS personalizzato e il tuo nodo di lavoro non entra in uno stato Normal o Active, le regole per il resolver personalizzato DNS non vengono aggiunte al gruppo di protezione kube-<clusterID> prima che siano necessarie alla logica che distribuisce i nodi di lavoro.

  1. Elencare i dettagli del gruppo di sicurezza kube-<clusterID> per verificare che gli IP del resolver DNS personalizzato vengano aggiunti come destinazioni nel gruppo di sicurezza.
    ibmcloud is sg kube-<clusterID>
  2. Sostituisci i nodi di lavoro del tuo cluster.
    ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
  3. Se il problema persiste, contattare il supporto. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere i file di log, i messaggi di errore o gli output dei comandi pertinenti.