1. Comprender el flujo de conexión de clúster

El siguiente diagrama muestra el flujo de conexión para un clúster VPC con puntos finales de servicio privados para conectarse a la consola web OpenShift. Este diagrama asume que el clúster tiene la configuración predeterminada de OAuth. Revise este diagrama y las siguientes descripciones para comprender mejor qué pasos de solución de problemas podrían ser necesarios.

1. El navegador web se conecta a través de la VPN al servidor API maestro del clúster. Se intercambia un certificado firmado y una redirección indica al navegador web que se conecte al equilibrador de carga de la consola OpenShift.
2. (a) El navegador web se conecta a través de la VPN al equilibrador de carga de la consola OpenShift que expone la consola OpenShift. (b) Esta solicitud se envía a uno de los dos pods de la consola openshift.
3. El pod de consola openshift se conecta al puerto del servidor OAuth maestro del clúster para comprobar si la conexión ya está autenticada. Si la solicitud ya está autenticada, la conexión a la consola web OpenShift está completa y se puede acceder a la consola web. Si la solicitud no está autenticada, el usuario es redirigido al servicio OAuth del clúster en el maestro del clúster.
4. El navegador web se conecta a través de la VPN al puerto del servidor OAuth del clúster, que redirige al cliente a IAM.
5. El navegador web se conecta a IAM a través de la red pública. El usuario introduce su contraseña y, si es necesario, una verificación de identidad ( 2FA ). Si este paso se realiza correctamente, el usuario es redirigido de nuevo al servidor OAuth del clúster.
6. El navegador web se conecta de nuevo a través de la VPN al puerto del servidor OAuth del clúster. La conexión se redirige de nuevo al equilibrador de carga de la consola OpenShift.
7. El navegador web se conecta a través de la VPN al equilibrador de carga de la consola OpenShift, que expone la consola OpenShift. Esta solicitud se envía a uno de los dos pods de consola openshift, que a su vez se conectan al puerto del servidor OAuth maestro del clúster para comprobar si la conexión ya está autenticada. Si el usuario ha introducido su contraseña y la verificación de 2FA, la autenticación se valida y el usuario se conecta a la página web principal de la consola OpenShift.

2. Compruebe su VPC y la configuración del clúster

Verifique que su VPC y clúster estén configurados correctamente. Una configuración incorrecta podría impedirle acceder a la consola web OpenShift.

1. Asegúrese de que su navegador web se esté ejecutando en un sistema cliente que esté dentro de la misma VPC que su clúster o que tenga una conexión VPN a esa VPC. La consola de OpenShift está expuesta por un equilibrador de carga de VPC privado al que solo se puede acceder desde la red privada de la VPC.

2. Asegúrese de que el sistema del cliente tiene acceso a los puntos finales de servicio público para IAM, a los que se puede acceder a través de iam.cloud.ibm.com y login.ibm.com.

3. Para clústeres que ejecutan la versión 4.13:

   • Si su clúster utiliza la configuración predeterminada de Oauth de 4.13 o si ha configurado su clúster para que utilice la pasarela VPE para Oauth, asegúrese de que su cliente utiliza el DNS privado para la VPC y que este tráfico DNS se enruta a través de la VPN a la VPC. El DNS privado suele ser 161.26.0.7 y 161.26.0.8, a menos que utilice un solucionador de DNS personalizado. Esto es necesario para que la puerta de enlace VPE para apiserver y Oauth, que no existe en ningún DNS público, pueda encontrarse en el DNS privado de la VPC.

4. Para clústeres que ejecutan cualquier versión compatible que no sea 4.13:

   • Si utiliza la configuración predeterminada del clúster Oauth, asegúrese de que existen rutas en la configuración de la VPN para que todo el tráfico de 166.8.0.0/14 se enrute a través de la misma VPN u otra VPN que se conecte a IBM Cloud. Esto es necesario para conectarse al servidor API del clúster y a los puertos del servidor OAuth.

3. Recopilar datos de clúster

Siga estos pasos para recopilar la información del clúster necesaria para la resolución de problemas. Los resultados que recopile con estos comandos se utilizarán en pasos posteriores.

1. Busque el servidor API del clúster URL. En comandos posteriores, este URL se denomina ${CLUSTER_APISERVER_URL}.

   1. Ejecute el mandato ibmcloud ks cluster get -c <cluster-id>.

      ibmcloud oc cluster get -c <cluster-id>
      

   2. En la sección " Master " (Información de la transacción) del resultado, busque el " URL " (Código de referencia de la transacción). La dirección de correo electrónico ( URL ) debe tener el siguiente formato: https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<YYYYY>.

2. Busque el grupo OAuth URL. En comandos posteriores, este URL se denomina ${CLUSTER_OAUTH_URL}.

   1. Ejecute el mandato kubectl get --raw /.well-known/oauth-authorization-server | grep issuer. No utilice el comando ibmcloud oc cluster get -c <CLUSTER-ID>, ya que este comando podría devolver un URL diferente.

      kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
      

   2. En el resultado, busque el " URL " con uno de los siguientes formatos.
      • Si la pasarela VPE no se utiliza para OAuth: https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>.
      • Si se utiliza la pasarela VPE para OAuth: https://<CLUSTERID>.vpe.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>.

3. Busque el subdominio Ingress. En comandos posteriores, este subdominio se denomina ${CONSOLE_LOAD_BALANCER}.

   1. Ejecute el mandato ibmcloud oc cluster get -c <CLUSTER-ID>.

      ibmcloud oc cluster get -c <CLUSTER-ID>
      

   2. En el resultado, busque el subdominio que coincida con el siguiente formato: <CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud. Tenga en cuenta que si ha configurado un subdominio de entrada personalizado, el formato coincidirá con su configuración personalizada.

4. Verificar conexiones y solucionar problemas

Siga estos pasos para comprobar las conexiones descritas en el flujo de conexión. Si encuentra un problema con una conexión, utilice la información para solucionar el problema.

1. Verifique que Ingress esté en buen estado y que el router y las consolas estén en buen estado.

   1. Ejecutar los comandos.

      ibmcloud oc cluster get -c <CLUSTERID>
      ibmcloud oc ingress status-report get -c <CLUSTERID>
      

   2. Si el resultado muestra un estado de error, utilice la documentación de resolución de problemas de Ingress para resolver el problema.

2. Verifique que los operadores del clúster de OpenShift estén en buen estado.

   1. Ejecute el mandato.

      oc get clusteroperators
      

   2. Si el resultado muestra que algún operador no está en buen estado o no se está ejecutando en la versión actual, utilice la documentación de resolución de problemas de la versión del clúster de OpenShift para resolver el problema. O bien, puede buscar en la documentación de IBM y Red Hat cualquier error específico que se muestre.
   3. Si el operador de la consola no está específicamente sano, compruebe los registros de los pods openshift-console/console... y openshift-console-operator/console-operator... para ver si un grupo de seguridad, ACL o personalización de DNS está impidiendo que los pods se conecten al puerto OAuth o a la consola OpenShift URL. Un grupo de seguridad, ACL o DNS podría estar configurado de manera que impida la conexión.

3. Verifique que la conexión con el servidor API maestro del clúster se haya realizado correctamente.

   1. Ejecute el mandato. Especifique el apiserver de clúster URL que encontró en los pasos anteriores.

      curl -k -vvv ${CLUSTER_APISERVER_URL}/version
      

   2. Si la conexión no se realiza correctamente, realice las siguientes comprobaciones y resuelva cualquier problema que encuentre.
      1. Compruebe que el maestro del clúster está en buen estado ejecutando el comando ibmcloud oc cluster get -c <CLUSTER-ID>. Consulte Revisar el maestro de salud para obtener información sobre cómo resolver problemas del maestro de clúster.
      2. Compruebe que la parte del nombre de host de URL se resuelve a través de DNS. Utilice el comando dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1) y especifique el servidor API del clúster URL.
      3. Verifique que haya una ruta a través de su VPN que se conecte al servidor API del clúster URL.
      4. Si el apiserver del clúster URL contiene su ID de clúster (que indica que el clúster utiliza la pasarela VPE para la conexión con el apiserver del clúster), compruebe que el grupo de seguridad de la pasarela VPE para el maestro del clúster permite el tráfico desde su subred de cliente VPN. Siga los pasos de Acceder a la consola de OpenShift cuando el acceso OAuth esté configurado como puerta de enlace VPE.
      5. Compruebe si algún grupo de seguridad, ACL o ruta VPC personalizada aplicada a la VPN impide el tráfico entre la VPN y el servidor API del clúster. Puede probarlo permitiendo temporalmente todo el tráfico entrante y saliente a través del grupo de seguridad VPN y ACL y comprobando si esto resuelve el problema. Si es así, realice los cambios necesarios en sus grupos de seguridad, ACL o rutas personalizadas para permitir el tráfico.
      6. Compruebe si alguna regla de restricción basada en el contexto (CBR) del clúster impide que el cliente se conecte al servidor API del clúster. Puede probarlo añadiendo temporalmente una zona de red a su regla CBR que permita todas las IP y subredes. Si este cambio temporal resuelve el problema, realice los cambios necesarios en la regla para permitir el tráfico.

4. Verifique que la conexión al equilibrador de carga del clúster que expone la consola OpenShift sea correcta.

   1. Ejecute el mandato. Especifique el subdominio de entrada que encontró en los pasos anteriores.

      curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
      

   2. Si la conexión no se realiza correctamente, realice las siguientes comprobaciones y resuelva cualquier problema que encuentre.
      1. Compruebe que la parte del nombre de host del subdominio se resuelve a través de DNS. Utilice el mandato dig console-openshift-console.${CONSOLE_LOAD_BALANCER}.
      2. Verifique que haya una ruta a través de su VPN a este subdominio del balanceador de carga. Verifique que la ruta incluya todas las IP o subredes que utiliza el equilibrador de carga. El resultado del comando dig console-openshift-console.${CONSOLE_LOAD_BALANCER} incluye las IP y subredes actuales del balanceador de carga, pero tenga en cuenta que estas pueden cambiar a medida que el balanceador de carga se amplía o reduce.
      3. Si ha modificado algún grupo de seguridad, ACL o ruta VPC personalizada que se aplique al equilibrador de carga, compruebe si algún cambio o regla que haya aplicado impide la conexión. Si no ha modificado ninguno de estos componentes y utilizan los valores predeterminados, puede omitir este paso.
      4. Compruebe si algún grupo de seguridad, ACL o ruta VPC personalizada aplicada a la VPN impide el tráfico entre la VPN y el equilibrador de carga. Puede probarlo permitiendo temporalmente todo el tráfico entrante y saliente a través del grupo de seguridad VPN y ACL y comprobando si esto resuelve el problema. Si es así, realice los cambios necesarios en sus grupos de seguridad, ACL o rutas personalizadas para permitir el tráfico.

5. Verifique que la conexión con el servidor OAuth del clúster se haya realizado correctamente.

   1. Ejecute el mandato. Especifique el OAuth URL del clúster que encontró en los pasos anteriores.

      curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
      

   2. Si la conexión no se realiza correctamente, realice las siguientes comprobaciones y resuelva cualquier problema que encuentre.
      1. Compruebe que su maestro de clúster está en buen estado ejecutando el comando ibmcloud oc cluster get -c <CLUSTER-ID>. Consulte Revisar el maestro de salud para obtener información sobre cómo resolver problemas del maestro de clúster.
      2. Compruebe que la parte del nombre de host del OAuth URL del clúster se resuelve a través de DNS. Utilice el dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1) y especifique el cluster OAuth URL.
      3. Verifique que haya una ruta a través de su VPN al maestro de clúster OAuth URL.
      4. Compruebe si algún grupo de seguridad, ACL o ruta VPC personalizada aplicada a la VPN impide el tráfico entre la VPN y el servidor OAuth del clúster. Puede probarlo permitiendo temporalmente todo el tráfico entrante y saliente a través del grupo de seguridad VPN y ACL y comprobando si esto resuelve el problema. Si es así, realice los cambios necesarios en sus grupos de seguridad, ACL o rutas personalizadas para permitir el tráfico.
      5. Compruebe si alguna regla de restricción basada en el contexto (CBR) del clúster impide que el cliente se conecte al servidor OAuth del clúster. Puede probarlo añadiendo temporalmente una zona de red a su regla CBR que permita todas las IP y subredes. Si este cambio temporal resuelve el problema, realice los cambios necesarios en la regla para permitir el tráfico.

6. Verifique que la conexión con IAM se haya realizado correctamente.

   1. Ejecutar los comandos.

      curl -vvv https://iam.cloud.ibm.com/healthz
      curl -vvv -o /dev/null -s https://login.ibm.com/
      

   2. Si alguno de estos comandos falla, compruebe que el sistema del cliente puede conectarse a estas URL de forma fiable y que las URL no están bloqueadas por ningún cortafuegos del cliente o de la empresa. Tenga en cuenta que estas URL requieren acceso a la Internet pública.

5. Contactar con el servicio de asistencia

Si ha completado todos los pasos anteriores y no ha resuelto el problema, póngase en contacto con el servicio de asistencia. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir cualquier archivo de registro, mensaje de error o salida de comando relevante.