Pourquoi est-ce que je vois des échecs DNS après l'ajout d'un programme de résolution DNS personnalisé?

{: tag-vpc}[Virtual Private Cloud] 4.15 et versions ultérieures

Vous constatez des échecs DNS après avoir créé un résolveur DNS personnalisé dans votre VPC où un cluster 4.15 existe déjà.

Dépannage des problèmes liés à la configuration DNS personnalisée avec le stockage Satellite.

Dans chacun des cas suivants, synchronisez le groupe de sécurité kube-<clusterID> et remplacez les noeuds worker comme décrit dans les étapes suivantes. Notez que le problème peut ne pas apparaître immédiatement après la création et l'activation du résolveur dans le VPC. DNS inclut un cache qui peut résoudre la recherche de nom jusqu'à ce qu'un agent soit remplacé ou redémarré, ou que des pods soient redémarrés.

  • L'ajout ou le remplacement d'un noeud worker dans le cluster échoue et ibmcloud ks workers affiche un statut de noeud worker similaire au suivant
    Infrastructure instance status is 'failed': Can't start instance because provisioning failed.
  • L'exécution de oc get oc génère une erreur similaire à la suivante.
    dial tcp: lookup s3.direct.eu-de.cloud-object-storage.appdomain.cloud on 172.21.0.10:53: server misbehaving.
  • Le redémarrage d'un worker entraîne le passage des pods de ce worker à l'état « Terminating » (en cours de redémarrage), l'impossibilité d'accéder à la console Web OpenShift, ou le passage d'Ingress à l'état « Critical » (en attente de redémarrage).

Si vous avez activé un résolveur DNS personnalisé dans votre VPC avant de créer un cluster 4.15, alors Red Hat OpenShift on IBM Cloud ajoute automatiquement des règles pour autoriser le trafic via les adresses IP du résolveur DNS à votre groupe de sécurité géré IBM Cloud (kube-<clusterID>).

Toutefois, si vous activez un programme de résolution DNS personnalisé sur un VPC qui contient déjà un cluster 4.15, ces clusters existants perdent l'accès au DNS.

Pour corriger ce problème, autorisez l'accès aux programmes de résolution DNS sur vos clusters existants en synchronisant le groupe de sécurité kube-<clusterID>. La synchronisation du groupe de sécurité « kube-<clusterID> » ajoute des règles autorisant le trafic vers les adresses IP des résolveurs DNS.

  1. Recherchez l'ID de groupe de sécurité de votre groupe de sécurité kube-<clusterID>.

    ibmcloud is security-groups

  2. Synchronisez le groupe de sécurité.

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

  3. Remplacez les nœuds de travail de votre cluster.

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

  4. Si le problème persiste, contactez l'assistance. Ouverture d'un cas de support. Dans les détails du cas, veillez à inclure les fichiers journaux, les messages d'erreur ou les sorties de commande appropriés.

Autres scénarios

Conditions d'erreur pouvant être dues à la combinaison d'un programme de résolution DNS personnalisé dans le VPC et de clusters 4.15 dans le même VPC.

Si le cluster est créé après la création du programme de résolution DNS

Si vous créez un cluster 4.15 après avoir créé un programme de résolution DNS personnalisé et que votre agent ne passe pas à l'état Normal ou Active, les règles du programme de résolution DNS personnalisé ne sont pas ajoutées au groupe de sécurité kube-<clusterID> avant qu'elles ne soient requises par la logique qui déploie les agents.

  1. Répertoriez les détails du groupe de sécurité kube-<clusterID> pour vérifier que les adresses IP du programme de résolution DNS personnalisé sont ajoutées en tant que cibles dans le groupe de sécurité.
    ibmcloud is sg kube-<clusterID>
  2. Remplacez les nœuds de travail de votre cluster.
    ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
  3. Si le problème persiste, contactez l'assistance. Ouverture d'un cas de support. Dans les détails du cas, veillez à inclure les fichiers journaux, les messages d'erreur ou les sorties de commande appropriés.