¿Por qué veo anomalías de DNS después de añadir un programa de resolución de DNS personalizado?

Nube privada virtual 4.15 y más tarde

Se producen fallos de DNS tras crear un resolver DNS personalizado en su VPC donde ya existe un clúster 4.15.

Resuelve problemas de configuración de DNS personalizada con el almacenamiento Satellite.

En cada uno de los casos siguientes, sincronice el grupo de seguridad kube-<clusterID> y sustituya los nodos trabajadores tal como se describe en los pasos siguientes. Ten en cuenta que es posible que el problema no se detecte inmediatamente después de crear y activar el resolutor en la VPC. DNS incluye una memoria caché que puede resolver la búsqueda de nombres hasta que se sustituya o se reinicie un trabajador o se reinicien los pods.

  • La adición o sustitución de un nodo trabajador al clúster falla y ibmcloud ks workers muestra un estado de trabajador similar al siguiente
    Infrastructure instance status is 'failed': Can't start instance because provisioning failed.
  • Si ejecuta oc get oc, verá un error similar al siguiente.
    dial tcp: lookup s3.direct.eu-de.cloud-object-storage.appdomain.cloud on 172.21.0.10:53: server misbehaving.
  • Al reiniciar un worker, los pods de ese worker pasan a estar en estado « Terminating », la consola web OpenShift deja de abrirse o Ingress pasa a estar en estado « Critical ».

Si antes de crear un clúster 4.15 tiene habilitado un resolvedor DNS personalizado en su VPC, entonces Red Hat OpenShift on IBM Cloud añade automáticamente reglas para permitir el tráfico a través de las direcciones IP del resolvedor DNS a su grupo de seguridad gestionado IBM Cloud (kube-<clusterID>).

Sin embargo, si habilita un programa de resolución de DNS personalizado en una VPC que ya contiene un clúster 4.15, los clústeres existentes perderán el acceso a DNS.

Para corregir este problema, permita el acceso a los programas de resolución de DNS en los clústeres existentes sincronizando el grupo de seguridad kube-<clusterID>. Al sincronizar el grupo de seguridad « kube-<clusterID> », se añaden reglas que permiten el tráfico a través de las direcciones IP del resolutor DNS.

  1. Busque el ID de grupo de seguridad de su grupo de seguridad de kube-<clusterID>.

    ibmcloud is security-groups

  2. Sincronice el grupo de seguridad.

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

  3. Sustituye los nodos de trabajo de tu clúster.

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

  4. Si el problema persiste, póngase en contacto con soporte. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir los archivos de registro relevantes, los mensajes de error o las salidas de mandato.

Otros escenarios

Condiciones de error que pueden deberse a la combinación de un programa de resolución de DNS personalizado en los clústeres de VPC y 4.15 en la misma VPC.

Si el clúster se crea después de que se haya creado el programa de resolución de DNS

Si crea un clúster 4.15 después de crear un programa de resolución de DNS personalizado y el trabajador no entra en un estado Normal o Active, las reglas para el programa de resolución personalizado de DNS no se añaden al grupo de seguridad kube-<clusterID> antes de que las necesite la lógica que despliega los trabajadores.

  1. Liste los detalles del grupo de seguridad kube-<clusterID> para verificar que las IP del programa de resolución de DNS personalizadas se añaden como destinos en el grupo de seguridad.
    ibmcloud is sg kube-<clusterID>
  2. Sustituye los nodos de trabajo de tu clúster.
    ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
  3. Si el problema persiste, póngase en contacto con soporte. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir los archivos de registro relevantes, los mensajes de error o las salidas de mandato.